Declaration

We the undersigned, hereby declare that this project work is the result of our own research and no
part of it has been presented for any other degree in this university or elsewhere. We are solely
responsible for any errors in the work.

Name Signature

Wubeshet Work _____________________

Yohannes Debay ________________________

Danil Tesaka _____________________________

Mesrak Wubeayehu _____________________________

Eshetu Abebe _____________________________

Date of Submission

This project has been submitted for examination with our approval as a university
advisor.

Project advisor Signature Date

Mr. Abera G/Tsadik(M.SC). …………...... ……………….

i
 Approval Sheet

Chair Person Name and Signature

___________________________________________________

External Examiner

Internal Examiner

___________________________________________________

Advisor

___________________________________________________

Department Head

___________________________________________________

ii
 Acknowledgment
First of all, thanks to God for the finalization of this documentation. Second we would also like to
thank our Advisor Mr. Abera G/Tsadik (M.SC) for his impressive guidance and support for the
accomplishment of this work. Next, we would like to thank Mr. Husan the supermarket manager for
his response while we were gathering information. At the last but not the least special thanks for our
classmates for their great help and keeping us to reach today’s day.

iii
List of Tables
Table1.1 Responsibility of team member----------------------------------------------------------------------3

Table 1. 2 project schedule--------------------------------------------------------------------------------------10

Table 1.3 Project Budget----------------------------------------------------------------------------------------11

Table 2.1 Current User Description-----------------------------------------------------.----------------------13

Table3.1 Use case Identification-------------------------------------------------------------------------------17

Table 3.2 Scenario----------------------------------------------------------------------------------------------18

Table: 3:3 Use Case Documentation for Login use case----------------------------------------------------19

Table: 3:4 Use Case Documentation for Add User use case--------------------------------------------20

Table: 3:5 Use Case Documentation for Add Customer use case-------------------------------------21

Table: 3:6 Use Case Documentation for Add Item use case--------------------------------------------22

Table: 3:7 Use Case Documentation for Receive product use case-----------------------------------23

Table: 3:8 Use Case Documentation for Sale Item use case--------------------------------------------25

Table 4.1 logical relationship between User, Sales, Inventory---------------------------------------------53

Table 4.2 logical relationship between Category and Product-----------------------------------------54

Table 4.3 Logical relationship between product and customer----------------------------------------54

Table 4.4 Logical relationship between Product and Supplier----------------------------------------54

Table 4.5 Logical relationship between product and Receiver----------------------------------------55

Table 4.6 Product Category List-------------------------------------------------------------------------------55

Table 4.7 Customer List----------------------------------------------------------------------------------------55

Table 4.8 Inventory List--------------------------------------------------------------------------------------56

Table 4.9 Product List------------------------------------------------------------------------------------------56

Table 4.10 Product Receiving list-----------------------------------------------------------------------------56

Table 4.11 User list----------------------------------------------------------------------------------------------57

Table 4.12 Sales list---------------------------------------------------------------------------------------------57

Table 4.13 Supplier List----------------------------------------------------------------------------------------57

iv
 List of Figure
Figure 3.1 super market management system use case diagram------------------------------------------25

Figure 3.2 conceptual class diagrams--------------- -------------------------------------------------------26

Figure 3.3.Sequence diagram for logic----------------------------------------------------------------------27

Figure3.4 sequence diagram for registration ----------------------------------------------------------------28

Figure 3.5. sequence diagram for delete customer --------------------------------------------------------28

Figure 3.6 sequence diagram for update--------------------------------------------------------------------29

Figure 3.7 sequence diagram for brows product ----------------------------------------------------------30

Figure 3.8 sequence diagram for add product to catalog ------------------------------------------------30

Figure 3.9 sequence diagram m for payment ---------------------------------------------------------------31

Figure 3.10 sequence diagram for create new user---------------------------------------------------------31

figure3.11. sequence diagram for create new user---------------------------------------------------------32

Figure 3.12. sequence diagram for order item--------------------------------------------------------------33

Figure 3.13. Active diagram for log in -----------------------------------------------------------------------34

Figure 3.14. Active diagram for update customer ----------------------------------------------------------35

Figure 3.15 Active diagram for create new user -----------------------------------------------------------35

Figure 3.16 Active diagram for register ----------------------------------------------------------------------36

Finger 3.17 Active diagram for delete customer--------------------------------------------------------37

Figure 3.18 Active Diagram for add item to cart----------------------------------------------------------38

Figure 3.19 Active diagram m for order product--------------------------------------------------------38

Figure 3.20 Active diagram for payment-------------------------------------------------------------------39

Figure 3.21 State chart diagram ----------------------------------------------------------------------------40

Figure 3. 22 User interface prototype-----------------------------------------------------------------------41

v
Figure 3.23. Log in screen UI----------------------------------------------------------------------------------42

Figure 3.24 Supermarket Management System Home Page for Administrator ---------------------42

Figure 3.25. Supermarket management Home page for cashier------------------------------------42

Figure 3.26 Inventory Page User Interface ---------------------------------------------------------------43

Figure 3.27. Sales User interface----------------------------------------------------------------------------43

Figure 3.28 Supplier User Interface-------------------------------------------------------------------------43

Figure 3.29 Supplier User Interface------------------------------------------------------------------------44

Figure 3.30 Product Category User Interface --------------------------------------------------------------44

Figure 3.31 Supplier User Interface-------------------------------------------------------------------------45

Figure 3.32 Product Receiving User Interface---------------------------------------------------------------45

Figure 3.33 Customer list user interface ------------------------------------------------------------------46

Figure 3.34 Users Information Interface------------------------------------------------------------------46

Figure 3.35 Receipt User Interface ---------------------------------------------------------------------------46

Figure 3.36 Print Receipt User Interface ----------------------------------------------------------------47

Figure 4.1 System and Subsystem Decomposition-------------------------------------------------------49

Figure 4.2 Persistent Modeling for Supermarket Management System-------------------------------50

Figure 4.3 Component Diagram for Supermarket Management System ----------------------------51

Figure 4.4. Deployment diagram for super market system----------------------------------------------51

Figure 4.5 Boundary Diagram for Supermarket Management System---------------------------------52

Figure 4.6 ER-Diagram for Supermarket Management System---------------------------------------52

vi
Content

s
Acknowledgment..............................................................................................................................................iii
Abstract...........................................................................................................................................................xii
CHAPTER ONE.........................................................................................................................................1
1.1. Introduction...........................................................................................................................................1
1.2. Background of the organization..............................................................................................................1
1.2.1. Vision of the Supermarket................................................................................................................2
1.2.2. Mission of the Supermarket.............................................................................................................2
1.3. Statement of the problem........................................................................................................................2
1.4. Purpose of the Project.............................................................................................................................2
1.5. Team of composition..............................................................................................................................3
1.6. Objective of the project...........................................................................................................................3
1.6.1. General Objective.............................................................................................................................3
1.6.2 Specific Objective.............................................................................................................................3
1.7. Feasibility Study.....................................................................................................................................4
1.7.1. Technical Feasibility........................................................................................................................4
1.7.2. Operational Feasibility.....................................................................................................................4
1.7.3. Economic Feasibility........................................................................................................................4
1.8. Scope and limitation................................................................................................................................4
1.8.1. Scope of the project..........................................................................................................................4
1.8.2 Limitations of the project..................................................................................................................4
1.9 Significance of the Project.......................................................................................................................5
1.10 Methodology..........................................................................................................................................5
1.10.1. System Development Approach.....................................................................................................5
1.10.2. Software process model approach..................................................................................................5
1.10.3. Data Collection Method.................................................................................................................6
1.11. Development Tools...............................................................................................................................7
1.11.1. Language........................................................................................................................................7
1.12. Testing Process.....................................................................................................................................8
1.12.1. Unit Testing....................................................................................................................................8
1.12.2. Integration Testing.........................................................................................................................8
1.12.3. System Testing...............................................................................................................................8
1.13. Overview of the Project Phase..............................................................................................................9

vii
 1.13.1. The Project Initiation Phase...........................................................................................................9
1.13.2. Project Planning Phase...................................................................................................................9
1.13.3. Project Execution Phase...............................................................................................................10
1.13.4. The project Closing Phase............................................................................................................10
1.13.5. Project Schedule...........................................................................................................................10
1.13.6. Project Budget..............................................................................................................................11
CHAPTER TWO...........................................................................................................................................12
2. Description of the current system........................................................................................................12
2.1. Major Functions of the current system..................................................................................................12
2.2. Users of the current system...................................................................................................................12
2.2.1. Current User table..........................................................................................................................13
2.3. Drawback of the current system............................................................................................................13
2.4. Business rule current system.................................................................................................................14
CHAPTER THREE.......................................................................................................................................15
3. PROPOSED SYSTEM..............................................................................................................................15
3.1. Overview of System Analysis...............................................................................................................15
3.2. Functional Requirements.......................................................................................................................15
3.4. Performance Requirements...................................................................................................................17
3.5. System Model.......................................................................................................................................17
3.5.1. Scenarios one.................................................................................................................................17
3.5.2. Scenarios two................................................................................................................................18
3.5.3. Use Case (Use Case Description)...................................................................................................18
3.6 Analysis Models.....................................................................................................................................25
3.6.1. Use case Diagram...........................................................................................................................25
3.7. Object Model........................................................................................................................................26
3.7.1. Conceptual Class Diagram.............................................................................................................26
3.8. Dynamic Model....................................................................................................................................26
3.8.1. Sequence Diagram.........................................................................................................................26
3.8.2. Activity diagram.............................................................................................................................33
3.8.3. State Chart Diagram.......................................................................................................................39
3.8.4. User Interface Prototype.................................................................................................................41
3.9. Object Oriented User Interface Design.................................................................................................42
CHAPTER FOUR..........................................................................................................................................48
4. SYSTEM DEISINE MOBEL................................................................................................................48

viii
 4.1. Overview...............................................................................................................................................48
4.1.1. Purpose of the System....................................................................................................................48
4.1.2. Design Goals..................................................................................................................................48
4.2. System Architecture..............................................................................................................................48
4.2.1. Overview of System Architecture..................................................................................................48
4.2.2. Architectural Style.........................................................................................................................48
4.2.3. System Process...............................................................................................................................49
4.2.4. Subsystem Decomposition.............................................................................................................49
4.2.6. Component Diagram......................................................................................................................50
4.2.7. Deployment Diagram.....................................................................................................................51
4.2.8. Boundary Diagram.........................................................................................................................52
4.2.9. Database Design.............................................................................................................................52
CHAPTER FIVE...........................................................................................................................................58
5. CONLCUSION AND RECOMMENDATION........................................................................................58
5.1. Conclusions...........................................................................................................................................58
5.2. Recommendations.................................................................................................................................58
Reference……………………………………………………………………………………………...……….60

ix
Acronyms

COE Central of Excellence.

CPU Central processing unit.

CSS Cascading Style Sheets.

Acronyms (D)

DB Data Base

DBMS Data Base Management System.

ERD Entity Relationship Diagram.

Acronyms (G)

GB Gigabit.

GHz Gigahertz.

GUI Graphic user interface

Acronyms (H)

HD Hard disk.

HTML Hyper Text Markup Language.

Acronyms (I)

IDE Integrated Development Environment.

MB Megabyte.

MS Microsoft.

MySQL Structured Query Language.

Acronyms (N)

N/A Not assign.

Acronyms (O)

x
OOD Object-Oriented Design.

Acronyms (P)

PHP Hypertext Pre-processor.

Acronyms (R)

RAM Random access memory.

Acronyms (S)

SER South East Region.

Acronyms (U)

UML Unified Modeling Language.

Acronyms (W)

WAMP Windows (W) Apache (A), MySQL (M), PHP (P).

COE Central of Excellence.

CPU Central processing unit.

CSS Cascading Style Sheets.

DB Data Base.

DBMS Data Base Management System.

ERD Entity Relationship Diagram.

GB Gigabit.

GHz Gigahertz.

GUI Graphic user interface

HD Hard disk.

HTML Hyper Text Markup Language.

xi
 Abstract
This project is done with the main objective of designing an ecommerce system for Chuch
supermarket. An object oriented approach is employed to achieve the main objective of the project.
Close interaction with interview backed up by observation is used to model the user requirements in
to the actual software development process. The paper includes three chapters or phases. The first
phase covers the introduction, which contains background, Statement of problem, objective of the
project, benefits of the project, scope, and methodology and significant of the project. The second
phase covers the system features which contain existing system description, hardware requirement,
software requirement, user requirement, system requirement, functional requirement, and
nonfunctional requirement. The third phase covers system analysis which include system
requirement specification Use case diagram, Use case description, activity diagram and sequence
diagram.

xii
 CHAPTER ONE
1. INTRODUCTION

1.1. Introduction
Online-Commerce (electronic commerce) is the process of buying and selling products and services
over the Internet, utilizing technologies such as the Web, electronic data interchange, e-mail, electronic
fund transfers, and smart cards. In recent years, e-commerce has exploded, and future trends indicate
that more and more businesses will connect themselves to the Internet. It is now becoming imperative
for some organizations to engage in e-commerce in order to remain competitive.
There are various reasons why e-commerce is making an impact on the computing world. Businesses
have realized that there are lower start-up and overhead expenses. Running costs are also quite low
since the order processing is automated and there is no need to employ people to take care of this.
Before the start of e-commerce, businesses were often restricted and expansion was difficult. Since the
Internet is accessible from almost anywhere on the planet, businesses can have global exposure.
Businesses can also advertise thousands of products without incurring huge costs. It is clear that the
low-cost factor plays a major role in inspiring organizations to travel the e-commerce route.

1.2. Background of the organization

Adama Chuchu fruit supermarket is located in Oromia region of Adama city. It was established in 2003
E.C by Mr. Hussan. From early beginning its vision is providing and giving excellent service to its
customers.
Currently the supermarket has 3 employees including the manager and it gives service for more than
100 customers in a day. The supermarket works from 12:00am-3:30pm per a day.
Supermarket provides items that are very necessary to the society at large with fair payment and having
successive business reputation, its capital increases from time to time.
From day to day the company is becoming popular and wider in service. But the way of serving
customers is tidy, difficult to manage and inefficient in different aspects due to its low performance and
poor ability to host many costumers at a time so a better solution is required.
Then online-commerce is required to create and develop new model and to optimize the relationship
between the supermarket and the customer. Changing from shopping at the supermarket to online

1
shopping which improve productivity by shortening supply chains, reducing overhead cost, and
enabling ‘‘just -in-time’’ service.

1.2.1. Vision of the Supermarket

To become a famous class supermarket
To satisfy customers by giving a flexible and efficient service

1.2.2. Mission of the Supermarket

The mission of the supermarket is to play a major role in the market service cost-effectively for all
sectors of the economy and support the long term development of the country.

1.3. Statement of the problem

Chuchu supermarket has currently many problems that initiated us to develop online-commerce system.
This problem uses manual system to process data. For instance,
Different information about every situation of the supermarket is done by paper, inflexible service since
the supermarket can't hold many customers at once and it’s also hard to tell the items that are out of
stock, also items soon going to be expired.
Performance is also another problem since a customer has to wait in line while another customer is
being served.
Security is also one problem since there is no way of protecting the employees from being cheated.
Customers also waste their time and energy waiting for their turn to be served. In view of this, the E-
commerce technology will be implemented to facilitate efficient services for customers by avoiding
those previously mentioned problems.

1.4. Purpose of the Project

First the owner of the supermarket will benefit the most on the new system because it creates easy
atmosphere to manage and control the shopping activities in the supermarket. Also, with the new
system once deployed the supermarket will create more business opportunities by simplifying their
operation, thus it allows them to have more customers. Secondly the customers are benefited since they
can save their time, energy and can simply order items of their choice by just visiting the site and
creating an account.
The customers are benefited from this system since they save the time, they take to purchase from the
supermarket by simply ordering items of their choice just by visiting the site and order also perform
payment cash.

2
The other benefited part is the government because the proposed system stores prices and required tax
computations for the purchased from the supermarket. With the computerized computations of tax, the
payment or collection due for government can be prepared conveniently.

1.5. Team of composition

S.no Name Department Responsibility Phone No.

1 Danil Tesaka COSC Prepare Project Proposal 0911721219

2 Yohannes Debaye COSC System Analyst 0915320769

3 Mesrake Wubeyew COSC System Designer 0911490349

4 Eshetu Abebe Programmer 0910423076

5 Wubeshet Worku Test the System 0911490731

Table1.1 Responsibility of team member

1.6. Objective of the project

1.6.1. General Objective

The main objective of this project is to develop e-commerce system for Chuchu supermarket that is
reliable, secured and flexible by automating the current system.

1.6.2 Specific Objective

To achieve the general objective mentioned above the following are specific objective:
 To respond user request in time
 Study the current manual system
 Identifying the problems under the current system
 Requirement analysis of the system
 Design and Implement User Interface
 Design and Implement Database
 Develop and Test the major functionality of the system
 Determine functionality of the System
 Implementation of the whole system
 Testing the whole system

3
1.7. Feasibility Study

1.7.1. Technical Feasibility

Technical visibility helps to see how the project can be developed using existing resource or
technology. This project can implement using the existing resource like desktop/laptop that we used for
development and Mobile phone to check the performance of the application. Since all resource and
technology is available for development it is technically feasible

1.7.2. Operational Feasibility

This test of feasibility checks if the application works with least difficulties when it is developed and installed.
The users have knowledge of the application that means it is not difficult to use, simply they input their voice or
use Amharic language interface to use the application.

1.7.3. Economic Feasibility

The device we use for developing the application is not expensive

1.8. Scope and limitation

1.8.1. Scope of the project

The new system we are going to develop is targeted on the following functions.
Register new Users
Register Product Category
Register Product List
Record Supplier List
Record Customer List
Record Received Product List to the stock
Inventory Management
Sale different category of products
Print Sales Receipt
Display all information

1.8.2 Limitations of the project

This project does not calculate VAT according the rules and regulation of the country due to limitation of
knowledge of the team member about Taxation and due to COVID-10 pandemic that the project team member
did not get information about TAX from TAX professionals.

4
1.9 Significance of the Project
The main significance of this project is to provide Online marketing system for fruit super market for
customer with in the country or different country.
The basic benefits of this project include: -
. Convenience and Quick Service:
. Low Cost for Operations
. Measure and Track Results
. Demographic Targeting
. Global Marketing:
. Ability to Multitask
. 24/7 Marketing
. Automated, Tech-Savvy Marketing
. Data Collection for Personalization
. Diversified Marketing and Advertising
. Easy Tweaking to Your Marketing and Advertising Campaigns
. Instant Transaction Service
. Better Sales Relationships
. Time-Effective Marketing
. Continued Marketing Campaign
. Increase security
. It reduces wastage of time
. Provide quick security

1.10 Methodology

1.10.1. System Development Approach

The software developers use Object Oriented System Analysis and Design approach for the analysis,
design and development of this project

1.10.2. Software process model approach

We use Big Bang model for the design and development of this project. We select this model because
this model is ideal for small projects with one or two developers working together and is also useful for

5
academic or practice projects. We select this model because of the following advantages over the other
models:

Big Bang Model are as follows:

 This is a very simple model

 Little or no planning required
 Easy to manage
 Very few resources required
 Gives flexibility to developers

1.10.3. Data Collection Method

The following data collection method is used to determine the business requirement, functional
requirements and other requirements of the organization:

 Interview
 Direct Observation
 Existing Document Analysis (Existing document review)

1.10.3.1. Sit Observation

Advantages of observation data collection method includes direct access to research phenomena,
high levels of flexibility in terms of application and generating a permanent record of phenomena
to be referred to later. At the same time, observation method is disadvantaged with longer time
requirements, high levels of observer bias, and impact of observer on primary data, in a way that
presence of observer may influence the behavior of sample group elements.

1.10.3.2. Interview
T information about the existing supermarket system, we interview the supermarket manager and some
customers about the services that are given to them, and the problems associated with that environment.
Practical Observation: During this time, we had directly entered in to the internal activities of the
supermarket to view what things are done? And what are the limitations and strength of the
supermarket? The essentiality of this method is that, to be confident with the data that we collect using
an interview method because o get the basic nowadays the reliability of peoples decreases time to time

6
Document analysis: -to get more information about the details of fruit supermarket we will refer to
some documents from the supermarket

1.10.3.3. Document review

Document analysis is a form of qualitative research that uses a systematic procedure to analyze
documentary evidence and answer specific research questions. Similar to other methods of analysis in
qualitative research, document analysis requires repeated review, examination, and interpretation of the
data in order to gain meaning and empirical knowledge of the construct being studied. Document
analysis can be conducted as a stand-alone study or as a component of a larger qualitative or mixed
methods study, where it is often used to triangulate findings gathered from another data source (e.g.,
interview or focus group transcripts, observation, surveys). When used in triangulation, documents can
corroborate or refute, elucidate, or expand on findings across other data sources, which helps to guard
against bias.

1.11. Development Tools

. Visual Pharadiay for UML

. Enterprise architecture

. Microsoft visual

1.11.1. Language
 Web Server (Wamp Server)-to manage and control the server side scripting program
 PHP-to develop the server side scripting program
 HTML, CSS, JavaScript-to develop the client side scripting program
 Enterprise Architecture-To design all UML diagrams of the system
 Software Project Management –to schedule the time requirement for the development of a system
 MySQL-to design and develop the database of this application program
 MS-Office-to write and edit the documentation part of the system
 Mozilla Firefox-to access or run the application program and the database of this project

7
1.12. Testing Process

1.12.1. Unit Testing

Unit testing is performed during the coding stage of a software development project to test individual
units of the application or functions of the project. It’s designed to test that each unit of the software
code performs as required or perform its required operations without errors. Therefore, this project tests
all units of the project such as login, database connect and to access home page of the project.

1.12.2. Integration Testing

This project is developed by showing integration between different sub-systems of the project. For
example, product category is integrated with the product list, the supplier sub system is integrated with
the product category and product list sub systems, the receiving sub system is integrated with the
product list sub system, and the sales sub system is integrated with the inventory sub system and etc.

1.12.3. System Testing

System testing is a testing of a complete and fully integrated software product. System testing is
performed in the context of a System Requirement Specification (SRS) and/or a Functional
Requirement Specifications (FRS). It is the final test to verify that the product to be delivered meets the
specifications mentioned in the requirement document. It should investigate both functional and non-
functional requirements. Therefore, this project tests the following types of testing practically after the
deployment of the software.

1.12.3.1. Functional Testing

This is a type of testing to verify that a system or a software product performs and functions correctly
according to user specifications. Accordingly, this project is tested practically to ensures that the
software or the system performs its required functions such as to add and delete users, sales a product,
make payment for the product sold, print a receipt, add product category and product list and etc.

1.12.3.2. Acceptance testing

Acceptance testing is performed by the client and verifies whether the end to end the flow of the system
is as per the business requirements or not and if it is as per the needs of the end-user. Client accepts the
software only when all the features and functionalities work as expected. Accordingly, this software is
practically accepted the user by fulfilling the requirements of the user as it is practically tested.

8
1.12.3.3. Deployment testing
Software deployment refers to the process of running an application on a server or device. A software
update or application may be deployed to a test server, a testing machine, or into the live environment,
and it may be deployed several times during the development process to verify its proper functioning
and check for errors. Another example of software deployment could be when a user downloads a
mobile application from the App Store and installs it onto their mobile device. To summarize, a
software release is a specific version of a code and its dependencies that are made available for
deployment. Software deployment refers to the process of making the application work on a target
device, whether it be a test server, production environment or a user's computer.

1.12.3.4. Security Testing and Access Control

Security Testing is a type of testing that ensures security to your software systems and applications.
It takes care of the fact that your systems are free from any vulnerabilities or threats or protect
unauthorized users not to access the supermarket management application software and the
database. Accordingly, the supermarket project management system uses session and cookies
functions during development. Therefore, both the database and application software not accessed
by unauthorized users or unregistered users. Only the admin can add, edit and delete the users, and
other information. The cashier did add users, and view those information or data which is only
visible to the admin and the database is only accessed by the admin.

1.13. Overview of the Project Phase

This part of the project is discussing about the system development project phase such as initiation of
the project planning of the project, execution of the project and until the completion of the project.

1.13.1. The Project Initiation Phase

This is a part of the project where, the team members are started to discuss each other for the project to
give responsibility for each group, selecting a project title and submission to the advisor and gets
confirmation of continuity to start a project.

1.13.2. Project Planning Phase

This phase of a project is to start to define a project scope, defining project schedule, identifying the
resource requirement for the development of the project and allocating a cost or a budget for the
development of a project. It is also the phase at which the team members determine the business
requirements of the system

9
1.13.3. Project Execution Phase
This the is the project phase that the system developers started to determine the functional requirements
of the proposed system, identifying the non-functional requirement of the system, designing of the
system, implementation of the system and testing of the system.

1.13.4. The project Closing Phase

This is the phase at which the project is closed and completed after the team members will conduct a
defense and submitted to the final project document and the software to the department of Computer
Science in the university.

1.13.5. Project Schedule

No Phases of System Time Duration
Development 1st week 1 st 2nd Month 3rd Month 4th 5th
month Month Month
1 Initiation of the Project
2 Planning
3 System Analysis
4 System Design
5 Implementation and
Testing
Table 1. 2 project schedule

10
1.13.6. Project Budget
No Materials, Equipment’s Description Units of quantit Unit Total
and others Measurement y Price Cost
1 Laptop Computer Corre-i5, 2.5GH pcs 1 28,000 28,000
500GB hard
disk, 4GB RAM
2 Printing Paper 2 Desta Desta 4 120 480
3 Internet 1000
4 Transportation Cost Per person 5 100 500
5 Software Wamp Server pcs 1 200 200
Total Cost 30,180

Table 1.3 Project Budget

11
 CHAPTER TWO

2. Description of the current system

The current system of Fruit supermarket which is a manual operation is based on product selling and
buying process to its customers and from supplier but mainly concern on selling products. The current
system has two employees and one manager, the employee works cooperatively with each other with
good approach. The customer on the other hand, visits the shop to physically shop and purchase the
fruit products from the supermarket

2.1. Major Functions of the current system

Input: The inputs in the supermarket are the items that are brought or purchased by the owner of the
supermarket from Adama. Another input is the customer transactions such as: quantities and price of
the products tendered by the shop. The owner of the supermarket does not have his own distributor to
get its resources constantly, but he purchases from the place where he can get the items that he wants at
proper, stable and appropriate cost.
Process: -The new items will be registered on the manual file of the supermarket.
- Ordering the items that are out of the stock
- Reporting all the activities that are done to the manager
Output: The main output of the supermarket is making the items ready to the customers and fair price,
including the summary of purchases.

2.2. Users of the current system

As the team tried to mention in the previous chapter, our system has many good things to offer over the
current system in many ways. The existing system is not securely supported system since it is manual.
It needs certain number of employees to manage the overall function of the system and it is not
effective and clear. The current system incorporates high number of employee as compared with
proposed system. That means a number of different actors can be incorporated in the existing system.
The actors involved in the current system are: -

12
2.2.1. Current User table
No. Users Descriptions
1 Manager He is responsible to manage the overall activities of the
supermarket
2 Supplier Those who supplies the supermarket products
3 Cashier Those who are working as cash collector or sale
t4 Stock Person A person(s)who control and manages the stock or the
inventory

Table 2.1 Current User Description

2.3. Drawback of the current system

As the team explained in chapter one, the existing system has many problems, which initiated the team
to develop a new computerized system to the supermarket. The performance of the existing system can
be evaluated by the time duration of the items waiting to be purchased by the customers and the number
of customers served at a time, and this depend on the number of customers and the number of
employees who give the service. If the numbers of the customers are more, the goods will only stay in
the supermarket shelf in short period of time which helps to drum-up the profitability of the
supermarket.
All the above statements are fulfilled if the employees can handle all the customers effectively and
quickly, but the existing system has a problem like:
 The numbers of employees needed to handle the customers are limited.
 It takes lot of time to calculate price of each items and serve many customers at the
same time.
 It is also time consuming in identifying the individual prices of each good.
Therefore, these problems make the performance of the existing system unsatisfactory.
Regarding to the information, the current system or the existing system has lack of the information in
terms of timeliness, accuracy and format. The team sees this section in terms of input and output.

13
Inputs:
 Loss of items information
 Fragmentation of information’s in different files
Output:
 In terms of producing report information to the manager
 In terms of getting remained item information.

Regarding the economic benefit of the system being proposed, it’s directly related to the performance,
as performance increases number of customers also increases which brings significant economic benefit
to the supermarket as opposed to the existing system performance
Which is low and this will make users unsatisfied and brings to a decrease of customers and also loss of
income, so the existing system is not a walk in the park.
Because supermarket is using the manual system there is weak side (weakness).
To mention some of these:
 Need of high energy and time for selling products because of its low ability to serve many
customers at a time.
 In saving the customer’s time because they have to wait long time until the employee calculate
the price of each item that they have purchased.
 Inability to give the service to more than two customers at a time

2.4. Business rule current system

The business has its own business rule and regulation which are followed to perform work in easier and
best manner. The businesses control the sales i.e. whenever the customer purchases any item. The
business must provide the receipt for each item that is sold to the customer.
When an item is purchased, the employee should have to fill all necessary information required from
him on the receipt after that the original receipt will be given to the customers and the copy of the
original receipt is left for the business unit and this receipt helps both the customers and the owner of
the business unit for the privacy purposes or else to certify either the customer or the owner would
purchase with an appropriate or exact price of the items or not because almost all items has some time
guaranties given by the business unit.
The customer can only pay in cash not using any other system. The customer and the seller have no full
guarantee for fault item and delay payment.

14
 CHAPTER THREE

3. PROPOSED SYSTEM

3.1. Overview of System Analysis

Object-Oriented System Analysis (OOSA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. The project team used
interviews with stakeholders for the analysis. The purpose of object oriented analysis is to develop a
model that describes computer software (Website) as it works to satisfy a set of customer defined
requirements.

System analysis consists modeling of the proposed system using object oriented methodology by
applying unified modeling language (UML). All the activities performed by the actors (such as the
customer, salesperson and the administrator) are analyzed by using different modeling diagrams. These
diagrams include use case diagram, sequence diagram, activity diagram, and conceptual diagram.

3.2. Functional Requirements

A requirement specification is an agreement between the end user and the system developer.
The new computerized system is expected to provide all ecommerce related services and
functionalities, like online selling of the product.
The new system is expected to provide the following functionalities:
 Register Users
 Purchas Products
 Receive Products
 Record Product category and Lists
 Sale Products
 Stock Products
 Print Receipt
 Generate Sales Reports
 View Customer Lists
 View Supplier of Products
 View Product Categories

15
  View Product Lists
 View Customer Lists
 View Inventory
 View Sales of the product
 Edit and Delete Product List
 Edit and Delete Customer
 Edit and Delete Sales
 Edit and Delete Products
 Edit and Delete users
3.3 Nonfunctional Requirements
There are different of nonfunctional requirements that are expected from the system.

These are:

 Performance: this system gives service24 hours per day with maximum response time so, it is easy to
access data from the stored document.
 Scalability: The system must be compatible with any environment
 Reusability: Ability of an item that allows it to be used repeatedly unlike a disposable item.
 Security: should allow login to only authorized users
 Reliability: The reliability of the proposed system will be better due to proper storage of information
when users access the application.
 No Redundancy: In the proposed system can be avoided reputation of data anywhere in the database.
 Accuracy: 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
 Availability: All data in the system will be available all the time.
 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.
 User friendly Interface: Users can easily input and retrieve their profile and history.
 Error handling Exception: The system must recover immediately when a user enters incorrect (error)
data.

16
 3.4. Performance Requirements
Which in general terms refers to specification in the contract for what is requested of the prevent partner
in terms of quality and/or quantity. Performance requirement may also be named output specification”,
and they may be referred to under the border concept of “operation and maintenances requirement”. The
technical requirements related to constriction may also be named “constriction requirement” or “technical
prescription for constriction”.

3.5. System Model

An object model is a logical interface, software or system that is modeled through the use of object-
oriented technique. It enables the creation of an architectural software or system model prior to
development or programming.

3.5.1. Scenarios one

No. Actors Descriptions

1 Admin A person who is responsible to manage the overall
supermarket system
Manage product list, product category, receive supplier
products and bring to the stock and controls the inventory
Manage Receiving Products
Manage sales
Manage inventory
Manage Customer
2 Cashiers A person who sales the product by login into the system
through user name and password
Manage inventory

Table3.1 Use case Identification

17
3.5.2. Scenarios two

Use Case Use cases Descriptions

ID
UI-01 Login The administrator and cashier must log into the system
before any operation performed
UI-02 Add User The system allows to add a new user as an administrator
or cashier and edit and delete users
UI-03 Add Customer The system allows the administrator to add a customer
UI-04 Add Item The system allows the administrator to add item to the
stock
UI-05 Add Supplier The supermarket system allows the administrator to add
suppliers of an item
UI-06 Inventory Control The system allows both the administrator and cashier to
controls the inventory in the stock
UI-07 Sale Item The system allows both the administrator and cashier to
sales an item and print the receipt
UI-08 Receive Product The system allows to receive a product from the suppliers
UI-09 Payment The system perform payment and print a receipt

Table 3.2 Scenario

3.5.3. Use Case (Use Case Description)

Use case description is a sequence of actions that provide measurable value to an actor. It is a way in
which a real world actor interacts with the system.

18
3.5.2.1. Use Case Documentation for Login use case

Name Login
Identifier UI-01
Description The Administrator log in to the system for using the system
Actor Admin
Pre-Condition The admin must log in into the system
Post Condition
Extends
Includes
Basic Course of Actions:
1. The user clicks the log screen page
2. The user enter user name and password3. The user click on Log in button
4. The system ensure the username and password in the database
5. The supermarket home page is displayed
6. The user perform its required operations
7. The System ends
Alternative Course of Actions: The user is registered user
1. The system ensures that the user is registered user
2. The system informs the user is not a registered user or if he/she entered a wrong user
name or password

Table: 3:3 Use Case Documentation for Login use case

19
3.5.2.2. Use Case Documentation for Add User use case

Name Add User

Identifier UI-02
Description The Administrator log in to the system to add a user
Actor Admin
Pre-Condition The admin must log in into the system before adding a user
Post Condition
Extends
Includes UI-01
Basic Course of Actions:
1. The administrator opens the log screen page
2. The administrator enters user name and password
3. The system displays a Home Page
4. The admin clicks the user tab from the left panel page of the Home Page
5. The System displays the user information Page
6. The User click on New Add User button
7. The system displays New User Page
8. The User input the necessary information and click on save button
9. The system displays data is successfully saved on the database
10. The user logout the page
11. The system displays the log in Page for the new user
Alternative Course of Actions: The user is registered user
1. The system ensures the administrator is a registered user
2. The system informs the user is not a registered user or if he/she entered a wrong user
name or password
3. The system returns the user to step 2
Table: 3:4 Use Case Documentation for Add User use case

20
3.5.2.3. Use Case Documentation for Add Customer use case

Name Add Customer

Identifier UI-03
Description The Administrator log in to the system to add a new customer
Actor Admin
Pre-Condition The admin must log in into the system before to add a new customer
Post Condition
Extends
Includes UI-01
Basic Course of Actions
1. The user opens the log screen page
2. The System displays the log screen page
3. The user input the user name and password and click on Login button
4. The system displays the Home Page screen
5. The user clicks on the Customer list tab from the left pan of the Home Page screen
6. The system displays the customer form page
7. The user input the customer information and click on save button
8. The system confirms and displays a message data successfully added and displays the
customer information to the right pan of the customer form page
9. The user logout from the system and leave the page
Alternative Course of Actions: The user is a registered user

Table: 3:5 Use Case Documentation for Add Customer use case

21
3.5.2.4. Use Case Documentation for Add Item use case
Name Add Item
Identifier UI-04
Description The Administrator log in to the system to add a new item or product
Actor Admin
Pre-Condition The admin must log in into the system before to add a new product or item
Post Condition
Extends
Includes UI-01
Basic Course of Actions
1. The user opens the log screen page
2. The System displays the log screen page
3. The user input the user name and password and click on Login button
4. The system displays the Home Page screen
5. The user clicks on the product list tab from the left pan of the Home Page screen
6. The system displays the product screen or form page
7. The user input the product information and click on save button
8. The system confirms and displays a message data successfully added and displays the product
information to the right pan of the product form page
9. The user logout from the system and leave the page
Alternative Course of Actions: The user is a registered user

Table: 3:6 Use Case Documentation for Add Item use case

22
3.5.2.5. Use Case Documentation for Receive Product use case
Name Receive Product
Identifier UI-08
Description The Administrator log in to the system to receive a product from the customer
Actor Admin
Pre-Condition The admin must log in into the system before to receive a new product or item
Post Condition
Extends
Includes UI-01
Basic Course of Actions
1. The user opens the log screen page
2. The System displays the log screen page
3. The user input the user name and password and click on Login button
4. The system displays the Home Page screen
5. The user clicks on the Receiving tab from the left pan of the Home Page screen
6. The system displays the New Receiving screen or form page
7. The userclicks on the New Receiving button
8. The system displays manage receiving page
9. The user selects the product category that previously inputted and the select the product list,
input the quantity received and the price of the product and click on add to list button
10. The system displays the necessary information with the totl cost of the product
11. The user clicks on save button
12. The system displays a confirmation page called data successfully added
13. The user logout from the system by clicking on the user tab to the right top corner of the page
14. The system displays a log screen page for another user
Alternative Course of Actions: The user is a registered user

Table: 3:7 Use Case Documentation for Receive product use case

23
3.5.2.6. Use Case Documentation Sale Item use case
Name Sale Item
Identifier UI-07
Description The Cashier log in to the system to sale item or a product
Actor Cashier
Pre-Condition The cashier is a registered customer and must log in into the system before start to
sale a product or item
Post Condition
Extends
Includes UI-01
Basic Course of Actions
1. The user opens the log screen page
2. The System displays the log screen page
3. The user input the user name and password and click on Login button
4. The system displays the Home Page screen
5. The user clicks on the sales tab from the left pan of the Home Page screen
6. he system displays the New Sales Page screen or form with its corresponding sales information
7. The user clicks on the New Sales button
8. The system displays sales page screen or form
9. The user selects the customer from the customer list and select the product from the product
category list and input the quantity that he/she need to sale
10. The system displays the sales information at the bottom of the sales page
11. The user clicks on the Pay button
12. The system displays a page that shows the total amount that a customer needs to pay

13. The customer clicks on pay button

14. The system displays a receipt page information

15. The user clicks on print button to print the receipt

16. The system displays a receipt page with a browser and printer dialog box on top of the receipt

page

17. The user selects the printer name and print the page and give to the customer

24
 18. The user logout from the system by clicking on the user tab to the right top corner of the page
19. The system displays a log screen page for another user
Alternative Course of Actions: The user is a registered user
1. The user sale an item if it is available in the stock.
2. If it is not available in the stock, go to step 9

Table: 3:8 Use Case Documentation for Sale Item use case

3.6 Analysis Models

3.6.1. Use case Diagram

Use case model describes the potential usage of the system, it is a part of the analysis of documents
which consists of use case diagram together with its documentation describing the use cases actors and
association, use case is also sequence of action that gives measurable value to actor.

Figure 3.1 Super Market Management System Use Case Diagram

25
3.7. Object Model

3.7.1. Conceptual Class Diagram

Class diagram shows the class of the system interrelationships and the options’ and attributes of the
class, a class is a representation of n object to describe a class we define its attributes and methods.
Information stored about an object while methods are what the object or the class does
Figure 3.2 Conceptual Class Diagram for Supermarket Management System

3.8. Dynamic Model

3.8.1. Sequence Diagram

Sequence diagrams are used to model the logic of usage scenario; usage scenario is exactly what it’s
have indicates the description of the potential ways your system is used the project team has modeled
sequence diagram for each use case identified in the use case modeling part.

26
 Customer Login screen Login Customer
(Actor) (Controller) User Interface

Login Actions
Click login

1 Customer click on login

2 Enter email and

password Enter email
and password
3 Validate email and Valid
Password Email and
Password
Invalid
4 Homepage
displayed
Customer
Create

Figure 3.3 Sequence diagram for login

27
 Customer Registration Registration
(Actor) (User (Controller) Database User Interface
Interface)
Registration
Actions Browse

1 Customer Brose
Validate input
2 Enter validate input Enter input Invalid

3 Success message Save input

Create

Figure 3.4sequence diagram for Registration

Administrator Customer Customer Administrator User Interface

(Actor) (UI) (Controller) (DB)

Deletion
Actions Select

1 Select delete

2 Enter id Enter ID
Display detail

3 Confirm Deletion Deleted

4 Success deletion Ask to confirm

Confirm
deletion
Create

Figure 3.5sequence diagram for delete customer

28
 Customer Update Update Customer User Interface
(Actor) (UI) (controller) (DB)

Update
Actions Update

1 Wish to update

2 Fill required input

Validate input
Fill input
Invalid
3 Validate filled input

4 Save update info Save update

Info
5 Display success
message
Create

Figure 3.6sequence diagram for Update customer

29
 Customer Product
UI
(Actor) (Controller)

Browse product
Actions

Request to view
2 System display product Product
Categor
y

Create

Figure 3.7sequence diagram for browse product

Store Product
Add product Add Product
Manager UI
Add product (UI) (Controller) (DB)
(Actor)
to catalog
Action

1 Store manager
Select add product

2 Enter Information Select Add

Product

3 System Validate input

Validate input
Enter product
Information
Invalid

Ask to confirm
Confirm
<<Create>>

Figure 3.8sequence diagram for add Product to catalog

30
 Customer Payment Authorize Payment Sales Person UI
(Actor) (UI) Purchase (DB) (Actor)

Payment
Action

1 Selects payment page Select Payment

page
Enter detail of Validate
Payment Payment
2 Customer enters detail
Information about payment Validate Input

3 System validate payment

Invalid Payment done
4 Customer validate payment
Process Ask for confirm
Get payment
detail Create
5 Sales person receive Confirm

Figure 3.9 sequence diagram for Payment

Administrator Create new User Create user Database

UI
(Actor) (UI) (controller) (DB)

Create new
user Basic
actions
Select
Enter user
1 Administrator information
Select create
new user page Validate
Information
Created
2 Enters valid Invalid
information
3 System validate << create>>
information

4System display
Success message

Figure 3.10 sequence diagram for create new user

31
 Administrator Create new User Create user Database
UI
(Actor) (UI) (controller) (DB)

Create new
user Basic
actions
Select
Enter user
1 Administrator information
Select create
new user page Validate
Information
Created
2 Enters valid Invalid
information
3 System validate << create>>
information

4System display
Success message

Figure 3.11 sequence diagram for create new user

32
 Customer Product Page Soping Cart
UI
(Actor) (UI) (Controler)

Order item request to order

Select Item

1.Customer Request
order

2 Customer select
list of orders

3 Customer order
the item

Displaye order Item «Create »

Figure 3.12Sequence diagram for order item

3.8.2. Activity diagram

Activity diagram is used to graphically depict the sequence flow of activities of either a business
process or a use case. They also can be used to model actions that will be performed when an operation
is executing as well as the result of those actions.

33
 Customer call to login

Enter Email and password

Incorrect

Corrected

Display screen

Figure 3.13Activity diagram for login

34
 Figure 3.14Activity diagram for update customer

Figure 3.15Activity diagram for create new user

35
 Browse site

Click on registration page

Enter required input

Incorrect
Correct

Register user

Figure 3.16Activity diagram for register

36
 Select delete customer

Enter customer id

Incorrect

Correct

Confirm deletion

No

Yes

Customer deleted

Figure 3.17Activity diagram for delete customer

37
 Select product page

Select added item

Add item to customer car

Figure3.18Activity diagram for add item to cart

Customer request to order

Select items from cart

Customer order the item

Figure 3.19Activity diagram for order product

38
 Figure 3.20Activity diagram for payment

3.8.3. State Chart Diagram

State chart diagrams show class states and the events that cause them to transition between states. It is
also called a state transition diagram. An event happens at a specific time and place. State chart
Diagrams are not created for all classes. It is created when a class has a complex life cycle, an instance
of a class may update its attributes in a number of ways through the life cycle, a class has an
operational life cycle and the object’s current behavior depends on what happened previously. The
following figures shows a sample state chart diagram for purchase class of supermarket management
system.

39
Finger 3.21 State Chart Diagram for Purchas class of Supermarket Management Syste

40
3.8.4. User Interface Prototype

Figure
3. 22 User interface prototype

41
3.9. Object Oriented User Interface Design

Figure 3.23 Login

Screen UI

Figure 3.24 Supermarket Management System Home Page for Administrator

42
Figure 3.25 Supermarket Management System Home Page for Cashier

Figure 3.26 Inventory Page User Interface

43
 Figure 3.27 Sales User Interface

Figure 3.28 Supplier User Interface

44
Figure 3.29 Supplier User Interface

Figure 3.30 Product Category User Interface

45
 Figure 3.31 Supplier User Interface

Figure 3.32 Product Receiving User Interface

46
 Figure 3.33 Customer List User Interface

Figure 3.34 Users Information Interface

Figure 3.35 Receipt User Interface

47
Figure 3.36 Print Receipt User Interface

48
 CHAPTER FOUR

4. SYSTEM DEISINE MOBEL

4.1. Overview
This part of the project is describing the object oriented system design that includes architecture of
the system, object oriented class diagram, collaboration diagram, State-Chart Modeling, Component
Modeling, Deployment Modeling, Persistent Modeling, User Interface Design of the project

4.1.1. Purpose of the System

4.1.2. Design Goals

The primary goals of system design are to translate the object oriented system analysis model into
structural design entities. This includes the specification of mechanisms and structures for managing
data, the control of the system as a whole, and performance requirements. The creation of subsystems is
managed by slicing large domains into smaller, manageable portions that can be worked on by two to
four persons. Another approach to the creation of subsystems is the clustering of related objects into
cohesive entities that can form a well-defined interface to other subsystems.

4.2. System Architecture

4.2.1. Overview of System Architecture

The System architecture is architecture shows mainly the hardware and software architecture and shows
the interaction between the layers of the architecture. It describes the subsystem decomposition in
terms of subsystem responsibilities, dependencies among subsystems, subsystem mapping to hardware,
and major policy decisions such as control flow, access control, and data storage.

4.2.2. Architectural Style

It is difficult to modify or correct weak decomposition once development has started, as most
subsystem interfaces would have to change. In recognition of the importance of this problem, the
concept of software architecture has emerged. A software architecture includes system decomposition,
global control flow, handling of boundary conditions, and inter subsystem communication protocols.
Therefore, the project team member selects Client/Server architecture style for the development of
supermarket software project management system. This architectural style is clearly shown in the
deployment diagram of this project.

49
4.2.3. System Process
Software Design is an iterative process through which requirements are translated into a “blueprint” for
constructing the software. It includes architectural design that escribes how software is decomposed
and organized into components (the software architecture) and the detailed design to describe the
specific behavior of these components

4.2.4. Subsystem Decomposition

The following figure shows the subsystem decomposition of supermarket management:

Figure 4.1 System and Subsystem Decomposition

50
4.2.5. Persistent Data Management
Persistent modeling is conceptually similar to design class modeling in terms of content. There are
minor things to remove and add in persistent modeling due to the nature of the DBMS to be used for
data management. The model describes the internal schema of a database, depicting the data tables, the
data columns of those tables, the unique nature of some functional columns (attributes) and the
relationships between the tables. The following figure shows the persistent modeling of the
supermarket management system.

Figure 4.2 Persistent Modeling for Supermarket Management System

4.2.6. Component Diagram

The component model illustrates the software components that will be used to build the system.
Component modeling emphasizes the separation of concerns in respect of the wide-ranging
functionality available throughout a given software system. The following figure shows the component
of a software developed for Supermarket management system.

51
Figure 4.3 Component Diagram for Supermarket Management System

4.2.7. Deployment Diagram

Figure 4.4 Deployment Diagram for Supermarket Management System

52
Deployment diagrams depict the physical resources in a system including nodes, components, and
connections. This model will be used to show how the hardware in the organization will be connected
and which component of the software will be deployed in hardware. The following figure shows the
component diagram of Supermarket Management System.

4.2.8. Boundary Diagram

Figure 4.5 Boundary

4.2.9. Database Design

4.2.9.1 Conceptual Database Design

This phase of the database design shows the theoretical design of the data requirement of the database
and it is illustrated by Entity Relationship Diagram. Accordingly, the following the following figure
shows the ER-Diagram of Supermarket Management System.

Figure 4.6 ER-Diagram for Supermarket Management System

53
4.2.9.2 Logical Database Design
Logical Database design shows the relational data of the database in a tabular form and it is illustrated
by Relational Data Mode. The following figure shows the logical database design of supermarket
management system.
1. Relational model between user and sales, and Inventory
User Table
User Name username Password user type
Id

Sales Table
I Reference- Customer- total amount amount date updated
d no id amount tendered change

Inventory Table
i Product- qty trype Stock from form-id date updated
d id

Table 4.1 logical relationship between User, Sales, Inventory

54
 2. Category and Product
Category Table
Id Name

Product Table
Id Category-Id Supply no price name Description

Table 4.2 logical relationship between Category and Product

3. Customer and Product

Product Table
Id Category-Id Supply no price name Description

Customer Table
Id Name contact Address

Table 4.3 Logical relationship between product and customer

4. Product and Supplier
Product Table
Id Category-Id Supply no price name Description

Supplier Table
Id Supplier Name contact Address

Table 4.4 Logical relationship between Product and Supplier

55
 5. Product and Receiving Table
Product Table
Id Category-Id Supply no Price name Description

Receiving Table
Id Reference No Supply ID Total Amount Date Added

Table 4.5 Logical relationship between product and Receiver

4.2.9.3. Physical Database Design

This part of the design shows the physical realization of the data in the database. Accordingly, the
following table shows the physical database design of supermarket management system.
1. Product Category List Table

Table 4.6 Product Category List

2. Customer List Table

Table 4.7 Customer List

3. Inventory Table

56
 Table 4.8 Inventory List
4 Product List Table

Table 4.9 Product List

4. Product Receiving Table

57
Table 4.10 Product Receiving list
5. Users Table

Table 4.11 User List

6.Sales Table

Table
4.12 Sales list
7. Supplier List Table

58
 Table 4.13 Supplier List

CHAPTER FIVE

5. CONLCUSION AND RECOMMENDATION

5.1. Conclusions
While developing the system a conscious effort has been made by the team member to analyses user
requirements, functional requirements and design and develop the supermarket management application
software or system by using different object oriented methodology, development tools and a software
package. The project team member follows the standard system development life cycle such as
planning, analysis, design, implementation, testing and deployment of the software. The project team
member writes the scripting code for different system and subsystem of this software application and
test each functionality to ensure that the software performs its required operations.
Accordingly, the project team member ensures that the supermarket management system
provides the following significant for product suppliers, users, sellers, and customers.
 The system can easily generates daily selling reports and allows a cashier to view the
products in the stock by easily clicking on inventory module or application.
 The system minimizes time for the customer, supplier, seller and other employees of the
supermarket by delivering the products with less time and getting services within short
time.
 The system can easily manage the products remained in the stock and allows to order the
supplier before all the products are stocked out.
 The system controls or manages the sellers if the product quantity needs to sold is less
than with the product in the stock and even the users can view the remaining products in
the stock before selling is performed
 The system can protect other users not to access the information of others
 The system performs all functionalities you identified in the analysis phase of the project
and ensures that it is user-friendly, flexible, and compatible with all other operating
system platforms.

59
5.2. Recommendations
As such one may hope that the system will be acceptable to any user and will adequately meet
his/her needs and performed all its functionality. As in case of any system development processes
where there are a number of shortcomings, there have been some shortcomings in the development of
this system also. The project is still under modification. For example, the project does not compute the
VAT and withholding for the product sold according to the taxation rules and regulation of Ethiopia.
And also there is shortcomings that the development team member lacks of skills to use different tools
such as time scheduling software and other UML diagrams. Therefore, the project team member
recommends other developers to modify and resolve the shortcomings of this application software. It
also recommended the project team member to modify after the will fill their skill gabs and will make
this software to commercialize.

60
Reference

1. S. Shim, V. Pendyala, M. Sundaram, and Ph. D Jerry Gao, Introduction to E-commerce, Special
issue on E-commerce in IEEE Computer, Vol. 33, No. 10, October, 2000.
2. Dr. Jim Arlow, OO Analysis and Design with UML and USDP, Version 2.0
3. Professor LonnineD.Bentlley “System Analysis and Design Methods” Simon Bennet, Steve
McRobb and Ray Farmer: Object oriented system analysis and design
4. Hoffer, Jeffrey A. and Georg, Joey F and Valacich, Joseph S, Modern Systems and Design,
Person Education (Singapore) ptc.Ltd, India Brench, 482 F.I.E Patperegieng, Delhi 110092,
India, 2000
5. Simon Bennet, SteveMcRobb and Ray Farmer: Object Oriented System Analysis and Design.
Websites
6. http://www.orderonline.sg/cart/
7. http://www.orderonline.sg/product/grapefruit-pink-500-g/
8. http://www.organicsupermarket.ie/shop/products/?category=1
9. http://www.waitrose.com/shop/Browse/Groceries/Fruit_and_Veg

61
 THANK YOU

62
63