WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING
PROJECT ON
ADULIS E-COMMERCE
BY
No NAME OF THE STUDENTS IDNO

1 MOHAMMED AHMED CIR/219/08

2 BINIYAM DANIEL CIR/073/08

3 MEWLED MOHAMMED CIR/212/08

4 SIMON EJETA CIR/416/07

5 BETHELHEM CHALCHISA CIR/067/08

6 ABAYENEH TADESSE CIR/001/08

PROJECT ADVISOR: ERMIYAS BIRHANU (MSC.)

Wolkite University, Wolkite, Ethiopia

February 2/18/2019
 WOLKITE UNIVERSITY
COLLEGE OF COMPUTING AND INFORMATICS
DEPARTMENT OF SOFTWARE ENGINEERING
ADULIS ECOMMERCE
SUBMITED TO DEPARTMENT OF SOFTWARE ENGINEERING
IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR
THE DEGREE OF BACHLER OF SCIENCE IN SOFTWARE
ENGINEERING
BY
No NAME OF THE STUDENTS IDNO

1 MOHAMMED AHMED CIR/219/08

2 BINIYAM DANIEL CIR/073/08

3 MEWLED MOHAMMED CIR/212/08

4 SIMON EJETA CIR/416/07

5 BETHELHEM CHALCHISA CIR/067/08

6 ABAYENEH TADESSE CIR/001/08

PROJECT ADVISOR: ERMIYAS BIRHANU (MSC.)

Wolkite University, Wolkite, Ethiopia

February 18, 2019
 DECLARATION

This is to declare that this project work which is done under the supervision of Ermiyas Birhanu
(MSc.) and having the title Adulis E-commerce is the sole contribution of: Mohammed Ahmed,
Biniyam Daniel, Mewled Mohammed, Simon Ejeta, Abayeneh Tadesse.
No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have been
cited properly. We will be responsible and liable for any consequence if violation of this
declaration is proven.

Date: _____________________

Group Members:

No NAME OF THE STUDENTS Signature

1 Mohammed Ahmed

2 Biniyam Daniel

3 Mewled Mohammed

4 Simon Ejeta

5 Bethelhem Chalchisa

6 Abayeneh Tadesse

i
 APPROVAL FORM

This is to confirm that the project report entitled Adulis E-commerce submitted to
Wolkite University, College of Computing and Informatics Department of software
engineering by: Mohammed Ahmed, Biniyam Daniel, Mewled Mohammed, Simon Ejeta,
Abayeneh Tadesse is approved for submission.

Advisor Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Department Head Name Signature Date

------------------------------------------------- ------------------------------ -----------------

Examiner 1 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 2 Name Signature Date

------------------------------------------------- ------------------------------ -----------------

Examiner 3 Name Signature Date

------------------------------------------------- ------------------------------ -----------------

ACKNOWLEDGEMENT

ii
We want to appreciate the almighty of God for the gift of life, protection, Health, academic
success and for giving us the strength to preparing the first-semester final project
documentation. We want to also in a special way appreciate our Parents for the support and
sponsorship of our education from initial to preparing the first-semester final project
documentation, for care, patience, and love we pray the Almighty God grants them long life
on earth to enjoy the fruit of their labor. We want to in a special way acknowledge our project
advisor Ermiyas Birhanu (MSc.). for his support in the realization of this project work. We
appreciate in a special way our department head Mr. Frazer Guteta who providing different
tools that help for doing this project. We appreciate all our friends and well-wishers whose
name were not mentioned we say our Lord reward you all what you want.

iii
TABLE OF CONTENTS

DECLARATION ....................................................................................................................... i
APPROVAL FORM ................................................................................................................. ii
ACKNOWLEDGEMENT ........................................................................................................ ii
TABLE OF CONTENTS ......................................................................................................... iv
LIST OF FIGURES ................................................................................................................ vii
LIST OF TABLES ................................................................................................................. viii
LIST OF ABBREVIATIONS .................................................................................................. ix
ABSTRACT .............................................................................................................................. x
CHAPTER ONE ....................................................................................................................... 1
1. INTRODUCTION ............................................................................................................ 1
1.1. Background of the Organization ................................................................................ 2
1.2. Statement of the Problem ........................................................................................... 3
1.3. The objective of the Project ....................................................................................... 4
1.3.1. General objective ................................................................................................ 4
1.3.2. Specific Objective ............................................................................................... 4
1.4. Feasibility Analysis .................................................................................................... 4
1.4.1. Operational Feasibility ........................................................................................ 5
1.4.2. Technical feasibility ............................................................................................ 5
1.4.3. Economic feasibility ........................................................................................... 5
1.5. Scope and limitation ................................................................................................... 5
1.5.1. The scope of the Project ...................................................................................... 5
1.5.2. Limitation of the Project ..................................................................................... 6
1.6. The significance of the Project ................................................................................... 6
1.6.1. The beneficiary of the Project ............................................................................. 6
1.7. Methodology for the Project ...................................................................................... 8
1.7.1. Data Collection Tools/Techniques ...................................................................... 8
1.7.2. System Analysis and Design ............................................................................... 8
1.7.3. System Development Model ............................................................................... 8
1.7.4. Testing Methodology .......................................................................................... 9
1.7.5. Development Tools and Technologies.............................................................. 10

iv
 1.7.6. Frontend Technologies...................................................................................... 10
1.7.6.1. Backend Technologies .......................................................................................... 10
1.7.6.2. Documentation and Modeling Tools .................................................................... 11
1.7.6.3. Deployment Environment .................................................................................... 11
1.8. Document Organization ........................................................................................... 12
CHAPTER TWO .................................................................................................................... 12
2. DESCRIPTION THE EXISTING SYSTEM ................................................................. 12
2.1. Introduction of Existing System ............................................................................... 12
2.1.1. Amazon ............................................................................................................. 13
2.1.2. Alibaba .............................................................................................................. 13
2.1.3. E-commerce in Ethiopia ................................................................................... 14
2.2. Users of Existing System ......................................................................................... 14
2.3. Major Functions of the Existing System .................................................................. 15
2.4. Forms and Other Documents of the Existing Systems ............................................. 16
2.5. Drawbacks of the Existing System .......................................................................... 16
2.6. Business Rules of the Existing System .................................................................... 16
CHAPTER THREE ................................................................................................................ 18
3. PROPOSED SYSTEM ................................................................................................ 18
3.1. Functional requirement of the proposed system ...................................................... 18
3.2. Nonfunctional Requirements.................................................................................... 20
1.2.1. User Interface and Human Factors ................................................................... 20
3.2.3. Security Issues .................................................................................................. 21
3.2.4. Performance Consideration ............................................................................... 21
3.2.5. Error Handling and Validation.......................................................................... 21
3.2.7. Documentation .................................................................................................. 22
CHAPTER FOUR ................................................................................................................... 23
4. SYSTEM ANALYSIS .................................................................................................... 23
4.1. System Model ........................................................................................................... 23
4.1.1. Use Case Model ................................................................................................ 23
4.1.1.1. Use Case Diagram ................................................................................................. 23
4.1.1.2. Use Case Description ............................................................................................ 29
4.1.1.3. Use Case Scenario ................................................................................................. 43
4.2. Object Model ............................................................................................................ 45
v
 4.2.1. Class Diagram ................................................................................................... 46
4.2.2. Data Dictionary ................................................................................................. 47
4.3. Dynamic Model ........................................................................................................ 49
4.3.1. Sequence Diagram ............................................................................................ 49
4.3.2. Activity Diagram .............................................................................................. 55
4.3.3. State Chart Diagram .......................................................................................... 58
CHAPTER FIVE .................................................................................................................... 65
5. SYSTEM DESIGN ......................................................................................................... 65
5.1. Design Goals ............................................................................................................ 65
5.1.1. Performance ...................................................................................................... 65
5.1.2. Dependability .................................................................................................... 65
5.1.3. Maintenance ...................................................................................................... 66
5.1.4. End user ............................................................................................................ 66
5.1.5. Priorities of Design Goal .................................................................................. 67
5.2. Current System Architecture .................................................................................... 67
5.3. Proposed System Architecture ................................................................................. 68
5.3.1. Subsystem Decomposition and Description ..................................................... 69
5.3.2. Hardware/Software Mapping ............................................................................ 72
5.3.3. Detailed Class Diagram .................................................................................... 73
5.3.4. Persistent Data Management............................................................................. 76
5.3.5. Access Control and Security ............................................................................. 78
5.4. Packages ................................................................................................................... 79
5.5. Algorithm Design ..................................................................................................... 80
5.6. User Interface Design ............................................................................................... 81
REFERENCES ....................................................................................................................... 84
APPENDICES A .................................................................................................................... 85

vi
LIST OF FIGURES
Figure 4-1Use case diagram.................................................................................................... 26
Figure 4-2. Detail Diagram and description for customer use cases ..................................... 27
Figure 4-3. Detail use case diagram for administrator ........................................................... 28
Figure 4-4. Detail use case Diagram for product Manager .................................................... 28
Figure 4-5. Detail use case diagram for Guest ....................................................................... 29
Figure 4-6. Class diagram ...................................................................................................... 46
Figure 4-7. Login sequence diagram ..................................................................................... 51
Figure 4-8. Register Sequence diagram ................................................................................. 52
Figure 4-9. Update product sequence diagram ...................................................................... 53
Figure 4-10. Checkout sequence diagram .............................................................................. 54
Figure 4-11. Activity diagram for Administrator side ........................................................... 55
Figure 4-12. Producer side activity diagram .......................................................................... 56
Figure 4-13. Customer and other activity diagram ................................................................ 57
Figure 4-14. Login state chart diagram .................................................................................. 58
Figure 4-15. register state diagram ........................................................................................ 59
Figure 4-16. Manage product state chart diagram ................................................................. 60
Figure 4-17. Search product state chart diagram ................................................................... 61
Figure 4-18.Comment for product state chart diagram ........................................................... 62
Figure 4-19. Rate State chart diagram ................................................................................... 63
Figure 4-20. logout State chart diagram ................................................................................ 64
Figure 5-1. Current system architecture................................................................................. 68
Figure 5-2. Proposed system architecture .............................................................................. 69
Figure 5-3. Subsystem Decomposition .................................................................................. 72
Figure 5-4. Deployment diagram ........................................................................................... 73
Figure 5-5. Persistent diagram ............................................................................................... 78
Figure 5-6. Package diagram ................................................................................................. 80
Figure 5-7. Web home page UI.............................................................................................. 82
Figure 5-8. Mobile register UI ............................................................................................... 83

vii
LIST OF TABLES
Figure 4-1. Use case diagram..................................................................................................26
Figure 4-2. Detail Diagram and description for customer use cases ......................................27
Figure 4-3. Detail use case diagram for administrator ............................................................28
Figure 4-4. Detail use case Diagram for product Manager .....................................................28
Figure 4-5. Detail use case diagram for Guest ........................................................................29
Figure 4-6. Class diagram .......................................................................................................46
Figure 4-7. Login sequence diagram ......................................................................................51
Figure 4-8. Register Sequence diagram ..................................................................................52
Figure 4-9. Update product sequence diagram .......................................................................53
Figure 4-10. Checkout sequence diagram ...............................................................................54
Figure 4-11. Activity diagram for Administrator side ............................................................55
Figure 4-12. Producer side activity diagram ...........................................................................56
Figure 4-13. Customer and other activity diagram .................................................................57
Figure 4-14. Login state chart diagram ...................................................................................58
Figure 4-15. register state diagram .........................................................................................59
Figure 4-16. Manage product state chart diagram ..................................................................60
Figure 4-17. Search product state chart diagram ....................................................................61
Figure 4-18.Comment for product state chart diagram ............................................................62
Figure 4-19. Rate State chart diagram ....................................................................................63
Figure 4-20. logout State chart diagram .................................................................................64
Figure 5-1. Current system architecture..................................................................................68
Figure 5-2. Proposed system architecture ...............................................................................69
Figure 5-3. Subsystem Decomposition ...................................................................................72
Figure 5-4. Deployment diagram ............................................................................................73
Figure 5-5. Persistent diagram ................................................................................................78
Figure 5-6. Package diagram ..................................................................................................80
Figure 5-7. Web home page UI...............................................................................................82
Figure 5-8. Mobile register UI ................................................................................................83

viii
LIST OF ABBREVIATIONS

No Abbreviation Description

1 E-Commerce Electronic – commerce.

2 NO Number.
3 UI User Interface.
4 CSS Cascading Style Sheets.
5 Mr. Mister.
6 GUI Graphical User Interface.
7 EC E-commerce.
8 XML Extensible Markup Language.
9 HTTP Hypertext Transfer Protocol.
10 HTML Hypertext Markup Language.
11 OOD Object Oriented Design.
12 OOA Object Oriented Analysis.
13 OOSAD Object Oriented System Analysis and Design.
14 UML Unified Modeling Language
15 ADMIN Administrator
16 USSD Unstructured Supplementary Service Data
17 MD5 Message Digest Algorithm
18 DDOS Distributed Denial Of Services

ix
 ABSTRACT
E-commerce is selling and buying a product online using the internet. E-commerce system is
the concept that describes how online buying and selling to proceed between buyer and seller.
Our system is a web-based and mobile-based system, so the user of our system can access the
system using mobile and other computer using the browser. in our e-commerce system, buyer
order product wants to buy. after order the product it goes fulfills shipping form which include
customer information, shipping type and shipping cost before make purchase, because of
amount shipping cost is calculated with amount of product cost. After doing that it makes
purchase through its account and money to be deposited on seller account and withdrawal from
customer account and manual form by using transporter take from customer. Finally, system
send message to both seller and buyer. Product manager is the person who store product
information and manage the product.

x
 CHAPTER ONE

1. INTRODUCTION

E-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 very important 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.
Running costs are quite low since the order processing is automated and there is no need to
employ people to take care of this. Before the advent of e-commerce, businesses were often
restricted and expansion was difficult. Since the Internet is accessible from almost anywhere
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.
The customer also reaps numerous benefits from e-commerce. They can shop whenever they
want, from the comfort of their homes and there is no need for them to even leave their houses.
All the hassles of driving to the store, finding parking and hunting for products, are eliminated.
After placing their orders, the customer can then sit back and wait until their goods are
delivered to their doorstep. Using traditional exchanging take a long time, not documented file,
not suitable in terms of speed.
Amazon is started out selling books but quickly expanded into other products, it has a presence
in nearly every consumer-oriented market, becoming a disruptive force in the retail space. In
Ethiopia, buying and selling products and services is in a traditional way. And that is not
reliable, secure and flexible. E-commerce system minimizes the time it takes in the buying and
selling process.

1
 To solve this problem, we are planning to develop a web-based and mobile app system. The
methodology our team will use in this project is an object-oriented system development
methodology (OOSD) for the design. This technique has several phases. In this technique, the
team performs modeling of the function of the system (use case modeling), find and identify
the business objects, organize the objects and identify the relationship between them and
finally model the behavior of the objects in detail.

1.1. Background of the Organization

Nowadays E-commerce is becoming popular and wider in service. It is required to create and
develop a new model and to optimize the relationship between the organization and the
customer. Changing from shopping to online shopping which improves productivity by
shortening supply chains, reducing overhead cost, and enabling ‘‘just-in-time’’ service.
The existing system, Amazon is started out selling books but quickly expanded into other
products. It has a presence in nearly every consumer-oriented market, becoming a disruptive
force in the retail space. Amazon provides product selling and buying process to its customers
and form supplier but mainly concern on selling products.

Amazon’s mission is to be earth's most customer-centric company; to build a place where

people can come to find and discover anything they might want to buy online.
The other existing system is Alibaba. Alibaba (or the Alibaba group) is China’s and by some
measures, the world’s - biggest online commerce company. Alibaba provides an online
platform for buyers and sellers, or rather multiple platforms, depending on the seller. It offers
free seller posting to attract small sellers. Alibaba handles more business than any other e-
commerce company. Alibaba Group's mission is to make it easy to do business anywhere.
The mission of Adulis is to become a large community of producer, consumer and deliverer
One person, one application and multiple choices. Our vision is to make marketing simple and
accessible across Ethiopia, in a way preventing inflation and dominance of foreign merchants;
we aim to enable customers to transform the way they sell, buy and deliver products. Adulis
main objective is to build a place where people can come to find and discover anything they
might want to buy online while making a profit for the seller.

2
1.2. Statement of the Problem
E-commerce can have a great impact on the growth of a county. And for a country like
Ethiopia whose economy is a non-oil economy, E-commerce is an essential tool for the growth
of the country. The current marketing system decreases market speed. And this makes our
country to face two major problems. The first one is, it gives other businesses the opportunity
to dominate the market, even with a substandard product simply because they got there first.
And the other is, it allows you to develop a reputation for being a follower rather than an
industry leader. As allafrica.com publishes on March 8, 2018 “Though it seems late, it is the
right time for the country (Ethiopia) to launch e-commerce as it eases the import-export
activities of companies installed in the newly built industrial parks, and hence penetrate into
the international market” Yohanes Jemaneh. Yohanes also states in his article that the main
reason why Ethiopia doesn’t have any e-commerce site is because of a poor internet connection
and very limited payment options. He also states that these problems have been solved due to
the Growth and Transformation Plan which stood at 3.2 gigabyte in 2009/10. Other major
problems of the existing system include:

• Accessibility of product: On some part of the country, a certain product is available in

one place and there is a deficiency of the same product on the other side of the country.
This causes a higher rate of inflation.
• Consumers don’t need to venture to the high street in order to buy items, instead,
consumers can shop from their own homes, making e-commerce a flexible solution
for both businesses and buyers. These days’ people don’t always have the time to
physically go shopping.
• Items found separately in the market place: In this case, customers use a long way to
get the items from producers.
• Lack of data storage which makes the manual system owner hard to hold track of
stock transaction.
• Inflexible service since the manual system 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;

3
 • Security is also one problem since there is no way of protecting the system from
cheating employees.
• The unavailability of credit cards: This is the main reason why E-commerce is not
widely used in our country. Because Ethiopian baking system support only support
post credit system and credit cards are not supported by banks yet.

1.3. The objective of the Project

Objectives state what the project will accomplish in terms of the business value to be achieved.
They serve as a basic tool to underlay all planning and strategic activities as well as to quantify
a level of performance. The objective of this project work is presented hereunder in terms of
general and specific objectives.

1.3.1. General objective

The main objective of this project is to develop an e-commerce system for Ethiopian that is
reliable, secure and flexible web-based and mobile application by automating the existing
system.
1.3.2. Specific Objective

• Study and analyze the existing system

• Design a system that considers the current situation and technology
• Select and implement the selected algorithm
• Design and develop new database
• Test and evaluate the proposed system
• Maintain and deploy the final product of the project

1.4. Feasibility Analysis

The feasibility study is used to investigate the proposed system in multiple dimensions. It is
used to indicate whether the system feasible or not. The feasibility study is an important phase
in both the research and software development process. It enables the developer to have an
assessment of the product being developed. It refers to the feasibility study of the product in
terms of outcomes of the product, operational use and technical support required for
implementing it.
4
 1.4.1. Operational Feasibility

It determines how the proposed system will satisfy the organizations need and it also offers
Secure, accurate and efficient system to the organization. The system performs all of its tasks
in a user-friendly manner. In which, anyone without an advanced technical background can
use the system. The system is also compatible with all operating systems and web browsers.
So, the project is operationally feasible.
1.4.2. Technical feasibility

Technical feasibility is the measure of the practicality of the specific technical support and the
availability of technical resources and expertise to use the system. The system is also easy to
maintain and is very much adaptable for change. Our development team has the required
knowledge to develop the functionalities of the system. So, the system will be technically
feasible.

1.4.3. Economic feasibility

Economic feasibility is the process of identifying the financial benefits and costs associated
with the project being developed. Economic feasibility is the process of identifying the
financial benefits and costs associated with the project being developed. We are using a free
hosting server and it doesn’t need a lot of resources. The development of the system requires
a minimum amount of cost. The estimated cost of resources that we use to develop this project
shown in table 1.1.

1.5. Scope and limitation

Project scope is the part of project planning that involves determining and documenting a list
of specific project goals, deliverables, features, functions, tasks, deadlines and ultimately costs.
A limitation is a restriction on the applicability of a project that may arise from the inability to
obtain sufficient appropriate evidence about a component in the financial statements

1.5.1. The scope of the Project

The new e-commerce system developed meets the following system and information
requirements.

5
 • Record products with their detail information
• Register new costumes
• Sell products
• Generate transaction
• Set the rates of taxes
• Select products and add to cart
• Display order information
• Display product information
• Display delivery information
• Works both mobile and web

1.5.2. Limitation of the Project

• The system considers business to customer. It is not considering the other type
of e-commerce
• The customer culture and language not considering all language in Ethiopia.
• The proposed system needs to fulfill customer needs, so it takes time.
• The existing system is traditional there is not get full information or collecting
this requirement is costive.
• The mobile application only targets android based platforms. Other platforms
like IOS, windows phone and blackberry are not supported

1.6. The significance of the Project

A significant project is defined as one that, alone or in combination with other concurrent
projects
1.6.1. The beneficiary of the Project

First, the owner of the system is most benefited from the system because it creates an easy
atmosphere to manage and control the shopping system and also benefit from the business role
since it can easily have many customers. The other beneficiary of the system is the product
provider. The product provider will have a number of audiences to view and rate their products.
Thus, the products will be advertised and promoted across Adulis web and mobile platforms.

6
The customers are benefited since they 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 time, they take to purchase from
the seller by simply ordering items of their choice just by visiting the site and order. Customers
can also perform electronic payment.

Employees of Adulis are also benefited from this system. Since Adulis opens a new job
opportunity for product managers and transporters, they will earn a decent amount of salary.
Banks are also another beneficiary of the project. Since mobile-based payment is supported in
the project, banks that support USSD based money transfer are advertised throughout the
process. The other benefited party is the government because it easily gets the items price and
the tax value associated with those items which ease the tax collecting process for it.
Customers (Buyers)
A person that is registered as a customer and interested in the ordering and buying process

• Wants to buy reliable products without being cheated

• Wants the product to be delivered within the time they will be home
• Want to reschedule the transport if they are not available
• Want to know which product is being bought by a lot of users
• Send a product request for a producer(seller)
Producers (seller) A person that is responsible for posting a product with the required
attributes. A person that is interested in posting a product
• Want to sell a product
• Want to distribute their product
Transporter (Delivery provider) A person that transport orders from the producer to the
customer
• Is an employee of Adulis
• Want to transport the products to the correct destination
Admin
• Want more to get user statistics
• Want to see the website traffic
• Register new employees

7
 • Check user interactions

1.7. Methodology for the Project

In order to accomplish this project on time and within the cost, we would follow different
procedures which are described below.

1.7.1. Data Collection Tools/Techniques

Data collection methodology is the way of gathering relevant data/information to study
problems of the current system.

➢ Observation: It is a useful data collection technique that assists the team to assess the
manual system by participating or watching in the real work and forms using in the
existing manual system. Here we have observed from already existing e-commerce
applications such as Amazon and Alibaba

➢ Document analysis: The team reviewed documents such as books, e-books and some
related previously done projects which are very important to develop our project.
During the analysis of documents, we give special consideration to those documents
which can bring more features to our system.

1.7.2. System Analysis and Design

➢ In this project, our team will use object-oriented system development

methodology (OOSD) for the design. This technique has several phases some of
them are:
➢ During this phase, the team model the function of the system (use case modeling),
find and identify the business objects, organize the objects and identify the
relationship between them and finally model the behavior of the objects in detail.
➢ During this phase, our team uses Edraw Max 9.2 software to refine the use case
model and those for designing the class diagram, sequence, collaboration, activity
diagrams, and state diagram and to model object interactions and behavior that
support the use case scenario.
1.7.3. System Development Model

Iterative model: Iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete system

8
is implemented and ready to be deployed. In the iterative model, we are building and improving
the product step by step. Our proposed system needs to consider unit testing and system testing,
for this reason, iterative is selected for our system.

1.7.4. Testing Methodology

Unit testing

Using unit testing is done at the source or code level for language-specific programming errors
such as bad syntax, logic errors, or to test particular functions or code modules. The unit test
cases shall be designed to test the validity of the program’s correctness. In this level of testing
process.
Sample Tests
• Check whether the return type of functions is correct.
• Check how the subprocedures or functions are called correctly.
• Check if the correct output is produced for different inputs.
• Check the efficiency of the code with respect to the memory and CPU time.
Integration testing
In this level of testing, we have examined how the different procedures work together to
achieve the goal of the subsystem. The type of integration testing that we have followed is
bottom up. So, we integrate each component from single functionality (individual interface) to
the main function incrementally.
Sample Tests

• Check the interaction between individual functionality which performs the specific
tasks.
• Evaluate the functionality of the subsystem after combination all individual
functionality.
• Identify the Independence of each subsystem with other subsystems.

System testing

In this level of testing process, we have examined how the whole e-commerce subsystems
came together to achieve the desired goal (user’s requirements of the system). The goals of
system testing are to detect faults that can only be exposed by testing the entire integrated

9
system or some major part of it. Generally, this testing is mainly concerned with areas such as
performance, security, validation, load/stress, and configuration sensitivity of Commerce. But
we will more focus only on function validation and performance.

Sample Tests

• Evaluate the functionality of the subsystem after a combination of individual subsystem

whether it works correctly or not.
• Check the coherence and coupling of each subsystem.
• Check the overall functionality of face recognition that achieves the user’s
requirement.
• Check the interaction of each subsystem that performs the specified business process.
• Verify the system completeness-based user’s requirement.

1.7.5. Development Tools and Technologies

A computer program that software developers use to create, debug, maintain, or otherwise
support other programs and applications. The term usually refers to relatively simple programs,
that can be combined together to accomplish a task, much as one might use multiple hand tools
to fix a physical object. The most basic tools are a source code editor and
a compiler or interpreter which are used ubiquitously and continuously.in our system use the
following development tool

1.7.6. Frontend Technologies

The user interface is developed using HTML, CSS, and JavaScript with React.Js integrated

development environment since it easily designing the front end and connected into database

realizing rapid application development with constraints on the hand

1.7.6.1. Backend Technologies

Node.js and Mongo database used in developing and managing at the back-end. Mongo
database software will be used for persistent data and backend management will be done by
Node.js.

10
Node.js:
• Is a server-side platform.
• Is an open source server environment.
• It allows you to run JavaScript on the server and It is free.
• Runs on various platforms
1.7.6.2. Documentation and Modeling Tools

Software tools: are software installed on a computer for a different purpose from
documentation up to the implementation. We describe in the following table 1.1
Table 1-1. software and hardware tool
Software tools Description
Microsoft Word 2016 For documenting the corresponding
deliverables associated with the project.
Edraw Max 9.2 For designing unified modeling language
(UML)diagrams.
Adobe Photoshop For design user interface.

Hardware tools: describe under the following table

Hardware tools Description

Computer (desktop or laptop) For documentation and implementation.

CD or flash disk For backup and storage.
Papers For notes.
Pen To write a requirement.

1.7.6.3. Deployment Environment

For testing purpose, we want to keep the deployment under localhost. But since our application
is a multiplatform app, we want to support data sharing between these platforms. So, we are
planning on deploying the web app over the cloud on Heroku servers. Since Heroku provide a
free trial version with 500 MB, we are planning to take that advantage. And as for the database.

11
1.8. Document Organization
• Chapter one defines and describes concepts with regard to the introduction of the
chapter that discusses problems in the existing system.
• Chapter two describe the existing system.
• Chapter Three is about Overview of proposed system which includes functional and
non-functional requirements.
• Chapter four Consists of a flow of events which is the scenario, use case model with its
description of the major use cases.
• Chapter five deals with system design. Which includes the overview of the system,
design consideration, design goal, design tradeoffs, the architecture of the System,
subsystem decomposition, persistent data management, and class interface.

CHAPTER TWO

2. DESCRIPTION THE EXISTING SYSTEM

2.1. Introduction of Existing System

E-commerce system provides product selling and buying process to its customers and form
supplier but mainly concern on selling products. The buyer benefits from a speedy,
straightforward, and predictable buying process. The dealer benefits by selling more products
and not paying a commission to a salesperson. The product provider receives the monthly
subscription fee from each dealer that it has under contract and sells advertising to insurance
and finance companies on its Web site

12
2.1.1. Amazon
The existing system of Amazon is started out selling books but quickly expanded into other
products. As of 2018, it has a presence in nearly every consumer-oriented market, becoming a
disruptive force in the retail space. The existing system of Amazon provides product selling
and buying process to its customers and form supplier but mainly concern on selling products.
There are a number of reasons customers have increased their spending on Amazon, including
excellent customer service, competitive prices, fast shipping, wide selection, and effective
digital marketing.
The first step of the buying process is to access Amazon's website and log into your account.
The website then changes based on your previous searches on Amazon and products
purchased. Thus, nearly everyone's Amazon experience is unique with a personalized layout.

Once you find a product you want to purchase, click Add to Shopping Cart. From there, you
are taken to a page where you must enter your shipping and billing information. Once you
enter this information and select your desired shipping option, click the final confirmation
button to complete the order.

Once a customer submits his order, Amazon's impressive backend system starts working.
Orders from third-party sellers are routed to Amazon, which takes a cut of those sales.
However, most orders go through Amazon's warehouses, which are spread out across the
world. These are stocked based on algorithms that predict the types and number of products
being ordered in that region.
These algorithms and fulfillment centers are one of the differentiators between Amazon and
other online retailers. They make up the secret sauce that allows the company to consistently
deliver faster and offer cheaper prices to customers. The Amazon backend routes the order to
the nearest fulfillment center, where a picker finds it. The product is packed and then placed
in a waiting delivery truck, depending on the shipping option. The entire process may only
take minutes from when the customer gives a final order confirmation before it is placed in the
delivery truck.
2.1.2. Alibaba
Alibaba is China’s and by some measures, the world’s biggest online company. Its three main
sites Taobao, Tmall, and Alibaba.com have hundreds of millions of users and host millions of

13
merchants and businesses. Alibaba handles more business than any other e-commerce
company. Alibaba is the most popular destination for online shopping, in the world's fastest
growing e-commerce market. Taobao is Alibaba's biggest shopping site. It's home to seven
million merchants selling everything from tiger-striped leather jackets to origami decorations.

2.1.3. E-commerce in Ethiopia

In Ethiopia, in order to sell products seller should have to go to marketplaces unless it sells its
product to people who live around. For this reason, movement from one place to another is
costly and a waste of sellers time. Sellers don’t know what type of product buyers need; the
buyer doesn’t know what kind of product sellers sell. Seller has difficulties of knowing if a
new product is introduced to the market, but people may need that new product so the seller
will losses benefits from the newly introduced product. A buyer is a person who pays money
in order to buy a product from the seller. Buyer should go to the market where products exist.
But the buyer doesn’t have any information which product exist and the price he/she expect to
buy something may not satisfy. Distribution of product information is in the form of paper
which become accessed only through peoples who are only in the marketplace and who uses
social media which are developed for other purposes. Buyer has difficulties in giving feedbacks
about products they bought before to other buyers and sellers.

Currently, there are e-commerce sites that give tiny information about products but these sites
have no true information about products. Also, delivery methods used by these e-commerce
sites are not efficient because in order to buy goods, buyers should have to communicate with
the seller physically and there is no payment mechanism that facilitates the buying and selling
process. We know that currently there are online payment services but these services don’t
have API for integrating them in websites easily like PayPal. so the existence of those problems
in developing country like Ethiopia causes a big impact on the economy and individual income
of every citizen of one country.

2.2. Users of Existing System

Amazon defines what it refers to as three consumers: sets customers, seller customers, and
developer customers. There are over 76 million customer accounts, but just 1.3 million active
seller customers in its marketplaces and Amazon is seeking to increase this. Amazon is unusual
for a retailer in that it identifies “developer customers” who use its Amazon Web Services,

14
which provides access to technology infrastructure such as hosting that developers can use to
develop their own web services.

The e-commerce system has been defined as the following user roles:
• Administrator: A paid user who has administrative permissions for the entire site,
including user management and site setting configuration
• Power user: A paid user of the site who can be given a special set of permissions by the
administrator.
• User: A paid user who can save files and collaborate with others in an Amazon Worksite.
• Guest user: An unpaid user who can only view files. Guest users can be upgraded to a
User, Power user, or Administrator.

2.3. Major Functions of the Existing System

Users are persons who are an external agent to the system. Those persons have directly
interacted to the system. This person is performing some actions like manage product,
managing producer, control the overall system, and e.t.c.by the users. Table 2.1. below
describe the users of the current system.

Table 2-1. current system

Users Responsibility Technical skill
Administrator • Overseeing Design • has a knowledge of
and Developments of the process of how
Website system work.
• manage product • Writing code,
manager, • Computer Skill and
• manage product, related knowledge
• control the overall the
system,
• Supervise all
activities and product
development
Product manager • Manage the product, • Has computer skill,
• budget effectively, • Communication
• maintain productive Skills
working relationships • know the payment
with the current mechanism of the
customer. system,

15
 Customer • Order the item, • Know the website
• fill the needs address
information, • The skill to access the
• tell the payment website
mechanism to pay the • Know the process of
appropriate value ordering and paying
• search for the system
product.

2.4. Forms and Other Documents of the Existing Systems

There are a number of forms and documents which are used by the existing system. The forms
are used during the period of the selling process. The uses of these forms are to assure the
correctness of their activity and to generate reports. In addition to this, these forms are used to
increase the relationship with customers. Some of the forms are illustrated in Appendix A.

2.5. Drawbacks of the Existing System

• The payment system is not compatible with countries that don’t support credit card
• The current website is user-friendly but the structural layout hasn’t been modified
• The current system is not working for Ethiopia.

2.6. Business Rules of the Existing System

A business rule is effectively an operating principle or policy the software must satisfy. The
Adulis E-commerce governs and controls the workflow through the following business rules.
These are rules and policy which are used to govern all actives in specified workflow, control
the workflow, and performed in the work environment. Our system Adulis e-commerce system
provides the following business rules for the user of the system.

• A product manager must respond to orders within 24 hours

• A report must be generated from the system
• A customer should be registered to the system
• Customers must provide their real personal data
• The customer must be registered in a certain bank in which he/she want to perform
an electronic-based transaction.
• The customer needs to have an account and sign in with password and account

16
• The item or the product must be available
• In addition to cash on delivery payment, the system supports online based payment
mechanisms
• The customer needs to order the item in order to get what they want
• Buyer should have a balance on its account in order to buy the product.
• The seller should be verified by the administrator of the system before storing its
product.
• The seller should open a bank account in order to receive the sold product money
and to pay for the agents.

17
 CHAPTER THREE

3. PROPOSED SYSTEM
3.1. Functional requirement of the proposed system
Functional requirement explains and describes the interaction between the system and the users
or in general with the environment. Functional requirement determines what the system can do
as well as input and output of the System. The proposed system is expected to provide all e-
commerce related services and functionalities, like online selling the product. In order for a
better understanding of our system, we divided the functionalities of our system by modules.
The new system is expected to provide the following functionalities:

User module
• Registering the user to the system
• Log in the user and redirect him/her to their respective landing page based on their role
(customer, product manager, transporter or admin)
• Update users’ profile: lets the user edit their profile
• View products – view products provided by producers(sellers) with their respective
category
• A customer can search for a product
• The customer can rate a product based on his/her satisfaction with a star. (0 - 5 stars)
• The customer can leave his/her thought on a product via the comment section
• The customer can add the product he/ she is interested in their cart
• The customer can then order the product by specifying their location and filling the
type of payment he/she prefers (through mobile banking or cash on delivery)
• The customer has to confirm that he has received their requested product
• The customer will have a reminder to remind him/her that he/she has a pending order.
• A product manager will have a section to manage product, add a new item, pending,
view customer request.
• A product manager will have a section in stoke and out of stoke product
• A product manager can remove their product from the system once the product is out

18
 of stock
• A product manager will have a section to view the profile of the transporter who is
delivering his/her product
• Transporter will have a section to see all the available orders that are open for delivery
• A transporter can check transporter details of the orders
• A transporter can confirm that he/she has delivered the product successfully
• An administrator can check review report of products
• An administrator will have a section to check user statistics like the number of active
users and number of Android installs
• An administrator will have a section to view another admins activity log

Inventory Module

• A product will have a category and a tag to help buyers on finding products easily.
• A product will have it’s a comment and rate section
• If the number of products is limited, the number of products should be specified
Pricing and payment modules

• If there is a discount on a certain product, the discounted price text will have a
strikethrough style and the discounted price will be in a plain text
• The system supports USSD based mobile banking
• The system also support money on delivery functionality, where a buyer pays the
deliverer; and the deliverer delivers the money back to the transporter
Cart and Order module

• The cart provides a list of organized products that the user is interested in
• A buyer can specify the number of products they want of the same product from the
cart
• For example, if a customer wants to buy 2 Computer mousses, he/ she doesn’t have to
order the same product twice. Instead, customers can specify the amount)
• The order will have its own time table
• An order can be removed by the user who has created it the first place

19
 3.2. Nonfunctional Requirements
Non-functional requirement describes the user-visible aspects of the system that are not
directly related to the system and not designated to functional behavior of the system and it
deals with the additional quality of the system.

Such as the following: -

1.2.1. User Interface and Human Factors

The interface of the proposed system is simple to understand, easy to use and user-friendly
interface and users of the system easily use and perform their task. Everything stems from
knowing our users, including understanding their goals, skills, preferences, and
tendencies. Once we know about our user, we consider the following list when designing our
interface:

• Keep the interface simple. The best interfaces are almost invisible to the user. They avoid
unnecessary elements and are clear in the language they use on labels and in messaging.
• Create consistency and use common UI elements. By using common element in our UI,
users feel more comfortable and are able to get things done more quickly, layout and design
throughout the site to help facilitate efficiency.
• Be purposeful in page layout. Consider the spatial relationships between items on the page
and structure the page based on importance. Careful placement of items can help draw
attention to the most important pieces of information and can aid scanning and readability.
• Strategically use color and texture. You can direct attention toward or redirect attention
away from items using color, light, contrast, and texture to your advantage.
• By carefully thinking about and anticipating the goals people bring to our site, we create
defaults in order to reduce the burden on the user.

3.2.2. Hardware Consideration

The Software product to be developed should run on existing computers and Android-based
smartphones. Our e-commerce system can run in any modern hardware devices.

20
 3.2.3. Security Issues
The system is much secured based on the username and password for all user activity. Nobody
can access the system without the authorized person. Passwords are not visible cannot be
accessed by anyone because the passwords are encrypted by MD5 encryption.

• All field entries are sanitized before any of them reach the database. By using the express
sanitizer, we can filter all entries and check for malicious content.
• User password shouldn’t be less than 8 characteristics to prevent social engineering attacks
• User password is hashed by using an MD5 algorithm-based module called bycript.js
• At the backend infrastructure, we are planning to use the passport.js, express-passport-
security.js and Local strategy.js modules which handles authentication and user data cache
and cookies
• And as for the frontend we are using React + Redux for authenticating the user
• Through these libraries, we can avoid DDOS attacks and Ping of Death attacks. Because
each request and its purpose is filtered at each step.
• User backend transaction and personal data are encrypted
• We have added an extra security layer of security for the transaction because these data is
sensitive. That is why we are using along with express-sanitizer, a very powerful tool for
encryption and authentication just made for this purpose.
3.2.4. Performance Consideration
The web-based system should have easy and efficient code manipulation and have clear
database. React.js also gives us a high rate of performance since it enables us to use reusable
components, it renders a lot faster. Thus, the response time should be very small i.e. not more
than 2.5 seconds. And we are confident that the android system will be much faster than our
website. Because android applications are usually 1.5 times faster than websites and they
perform actions much faster too.

3.2.5. Error Handling and Validation

The system will check user inputs to the system to handle error. It handles and show error by
in a user friendly manner, without exaggerating the user. We handle this errors in client side
by using React.js validator and the error type is sent from the backend tool Node.js. We use
front end validation to reduce the loading time of pages. If there is any server-side error, it is

21
only visible on the server log, they are not visible to the user. All the user will be notified is
that there was a server error. All the detail will be kept in the logs for the developers.

3.2.6. Backup and Recovery

The system includes a secondary database which is a copy of the original database used for a
backup purpose that is used for recovery if a problem is occurred with the original one.

3.2.7. Documentation

Our system Adulis ecommerce system has well defined document which helps to easily
maintain the system. We will also prepare short and precise help file on how to use the
system for the system users. It will have a helping guide for the user of the system. It shows
the process of how they will have to use.

22
 CHAPTER FOUR

4. SYSTEM ANALYSIS

System analysis is conducted for the purpose of studying a system or its parts in order to
identify its objectives. It is a problem-solving technique that improves the system and ensures
that all the components of the system work efficiently to accomplish its purpose. Analysis
model contains three models: functional, object and dynamic models. The functional model
can be described by use case diagrams. Class diagrams describe the object model. Dynamic
model can also be described in terms of sequence, state chart and activity diagrams. For the
purpose of this project, we have described the analysis model in terms of the functional model
and dynamic models using use case, sequence diagrams, Activity diagram, State diagram, and
class diagram

4.1. System Model

To describe the abstract models of our system we use the following use case model with each
of this use case model presenting of developing abstract models of the system. We can
represent our system by using different system models such as use case models, object models,
dynamic models, that describe the problem to be solved and as system models represented by
graphically, they are more understandable than more detailed natural language description of
the system requirement

4.1.1. Use Case Model

The Use Case Model (use case diagram, use case description, use case scenario) is used to
define the core elements and processes that make up our system. This Use Case Model capture
the functional system components. Because Use Case Models are simple in nature, this Use
Case Models are a great way to storyboard flows with users and define the system requirements
being modeled and help write the scenarios later used in testing.

4.1.1.1. Use Case Diagram

Use case diagrams are used for capturing functional requirements of the system. It is the
functionality of the system or the service provided by the system. In use case diagram it
better to consider the following elements.

23
 • Use case - which is the functionality of the system which directly interacts with the
user
• Actor - anything which interacts with the system.
• A relationship between the use case.
• Our system actor.
In this system we identified both actors and use cases (functionalities) as the following:
• Customer
• Guest
• Product Manager
• Administrator
• Transporter
• Product provider
The system has six actors and each actor can perform actions that are specific to a particular
role. Figure 4.1: below shows the use case diagram of the system.
• Customer
o A customer can log in into the system and log out from the system
o A customer can add a product to cart.
o A customer can view products.
o A customer can view notification
o A customer can view a historical list of sales orders.
o A customer can give comment on the product.
o A customer can give a rate for the product.
o A customer can check out.
• Guest customer
o Gust customer can be registered.
o Gust customer can view products.
o Gust customer can edit and add a product to cart.
• Product manager
o A product manager can log in into the system and log out from the
system
o A product manager can manage product

24
 o A product manager can view notification
o A product manager can be view pending orders
o A product manager can view customer request
o A product manager can perform stock management
o A product manager can assign transporter
o A product manager can agreement with product provider
• Administrator
o The administrator can log in into the system and log out from the
system
o The administrator can manage authorization
o The administrator can manage user
o The administrator can manage the product
o The administrator can manage profile
• Transporter
o Transporter can view detail transporter
o Transporter can receive payment
o A transporter can confirm delivered the product successfully
• Product provider
o Product provider can agreement with product manager

25
 General System Use Case

view Notification

Authoralization
Association

Login Association
Association

<<include>>

Association
Manage
Association

<<include>>
<<include>> Association
View histories
Association
Association
Association
Association
Association
Association
Association
Administretor
Register
ProductManager

Association
Order

<<extende>>
Association
Search product

Association
Feedback
Association
Association
Association
Association Association Customer
Association
Association Logout

Association
Guest Agreement

Association
View product
Association Association
Association
Association
Cart
Transporter Product Provider
Association
View transportation
detail Payment

Shipping
detail

Figure 4-1Use case diagram

26
Figure 4-2. Detail Diagram and description for customer use cases

27
Figure 4-3. Detail use case diagram for administrator

Detail use case for productManager

Manage product

Extend

Association Manage
Extend

ProductManager

Manage profile

Figure 4-4. Detail use case Diagram for product Manager

28
 Detail use case for viewer

Add product to cart

Extend
Association
Cart
Extend

Gust
Edit cart

Figure 4-5. Detail use case diagram for Guest

4.1.1.2. Use Case Description
The use case description is used to detail description of the use case what and how the use case
works in order to perform user and system functionality. In this project, we discussed detail use
case description as shown table 4.1 to table 4.19 below

Table 4-1. Login use case description

Use case name Login
Use case number 001
Description A user enters into the system.
Actor Product Manager, Customer, Administrator
Precondition The user should be registered.
Normal flow 1. User click on (login) link on the home page
2. The System display login page.

29
 3. User fulfills the username and password and then click on
(login) button
4. The System validates entered value.
5. now the user has access to his account (logged in).
6. The System display account page.
7. End use case.
Alternative flow 4.1.user enters invalid username and password
i. The System displays messages that contain “field cannot
be empty or you entered wrong username or password”
will be displayed.
ii. user repeat number 3 from the normal flow.
Postcondition The user will have access to his account.

Table 4-2. User register use case description

Use case name Register
Use case number 002
Description The user who is new for the system should be registered.
Actor Guest, Product Manager, administrator
Precondition Browse Adulis e-commerce website

Normal flow 1. User clicks (register) link on the home page

2. The System displays registration page
3. User fulfill the information that the system request and click
on (register) button
4. The System validates entered value from the user.
5. the system will Register user and display Successfully
registered message.
6. The System display home page.
7. Use case end

30
 Alternative flow 4.1. The user enters invalid information
i. The System displays a messages that contain “field cannot
be empty or you entered a wrong value” will be displayed.
ii. User repeat number 3 from the normal flow

Postcondition Login into the system and do another activity.

Table 4-3. View notification use case description

Use case name View Notification
Use case number 003
Description Notifications that are sent to the user
Actor Product Manager, Customer, Administrator
Precondition Users should be registered.
Normal flow 1. User clicks on (notification) link on home page.
2. The System displays generated notification.
3. User view notification
4. Use case end

Alternative flow Nothing

Post condition Get important information

Table 4-4. Add to cart use case description

Use case name Add to cart
Use case number 004
Description Order the product
Actor Guest and customer
Precondition Adulis E-commerce website should be displayed.
Normal flow 1. User clicks on (add to cart) button on a selected product
on the product page.
2. The System will add the product to cart

31
 3. Use case end.
Alternative flow Nothing
Postcondition Edit cart product, shipping and make a purchase.

Table 4-5. Edit cart use case description

Use case name Edit cart
Use case number 005
Description Delete or update product from cart.
actor Customer and Gust.
Precondition Adulis e-commerce website should be displayed, the product
should be added into the cart.
Normal flow ✓ Case update
1. customer select (cart) link on the home page
2. the system will display customer product which added
into the cart with previous information.
3. customer edit product information and click on (update)
button.
4. The System validates entered input.
5. The system will display “successfully Updated message”
and display the Updated page.
6. Use case end.
✓ Case deletes
1. customer select (cart) link on home page and the system
displays customer product which added into the cart with
previous information.
2. The user selects (delete) button and The System displays a
message that contains” are you sure you want to delete
with yes and no button”

3. user select (yes) button, the system deletes the product

from the cart list and display successfully deleted
message.

32
 use case end.
Alternative flow 4.1 user enter wrong input or left blank fields on updating cart.
i. The System displays Messages that contain “field cannot
be empty or you entered the wrong character” will be
displayed
ii. User repeat 3
4.2 users select(no) button on deleting cart.
The System cancels deleting action
Postcondition Data will be deleted from the database and previously existing
product information will be updated.

Table 4-6. Payment Use case description

Use case name Payment
Use case number 006
Description Payment is the electronic exchange or transfer of money
from one account to another or exchange of money in
manual.
Actor Transporter, Customer, Gust
Precondition Add a product into a cart.
Normal flow 1. The user is on payment page login form.
2. user fulfill the username and password and then click on
(login) button.
3. The system validates entered input.
4. The system warned the customer that some amount of
money will be withdrawn from his amount for some
products with next and cancel button and the user clicks
on (next) button
5. The system check amount balance user has from its
account.

33
 6. The system deposit money on producer account,
withdraw money from the user account and send a
message to both producer and user.
use case end.
3.1 User enters invalid username or password
Alternative flow i. The System displays messages that contain “field
cannot be empty or you entered wrong username or
password” will be displayed.
ii. User repeat number 2 from the normal flow
4.1 user clicks on cancel (button)
i. Cancel paying
5.1 user has no sufficient amount
The System displays messages that contain “you don’t have
enough account to purchase” will be displayed.
Postcondition Money is withdrawal from customer and deposit to the
producer.

Table 4-7. View product detail use case description

Use case name View Product Detail
Use case number 007
Description Viewing products detail information
actor Customer and Gust.
Precondition Adulis e-commerce website should display.
Normal flow 1. User clicks on (detail) button on a selected product on the
product page.
2. The System will display the product detail information.
3. User view the detailed information
4. Use case end.
Alternative flow Nothing.
Postcondition Get extra information about products

34
Table 4-8. Use case description for manage user
Use case name manage user
Use case number 008
Description Controlling and identifying the user of the system.
Actor Administrator.
Precondition if the user is Product Manager the pre-condition is seller first
should be registered and describe products description, he/she
wants to sell. The Product Manager should become an e-
commerce organization physically and make an agreement with
Administrator in order to use their website. But if the user is a
customer the pre-condition is customer should be registered in
the system and Administrator should be on the dashboard page.
Normal flow ✓ If the user is producer and Administrator, select (delete)
button on manage seller page.
1. The System display “are you sure you want to delete the
message” with yes and no button.
2. the user selects the (yes) button, the system deletes the
seller and display successfully deleted message.
3. Use case end.
✓ If the user is customer and administrator, select (delete)
button on “the manage” customer page
1. The system display, are you sure you want to delete the
message with yes and no button
2. if the administrator select (yes) button, the system
deletes the member and display successfully deleted
message.
Use case end.
1.1. administrator clicks (no) button
Alternative flow Nothing will be deleted
Postcondition data of both producer and customer will be edited.

35
Table 4-9. Search product use case description
Use case name Search product
Use case number 009
Description looking for a specific product
actor Customer, Gust
Precondition An ecommerce website should be displayed.
Normal flow 1. User clicks on the search icon on the home page.
2. The System will generate a search box and the user enters
text.
3. System validate and display the search results
Use case end.
Alternative flow 3.1. The system display not found
Postcondition Get information about a specific product

Table 4-10. Profile use case description

Use case name Manage Profile
Use case number 010
Description Users manage their profile information
actor Administrator, Product Manager, and Customer.
Precondition users should have their own account in the system and they
should log into the system and they should be in the dashboard
page (Administrator and Product Manager) or setting
(Customer) page.
Normal flow ✓ If one of user select (profile) link in the dashboard
(Administrator and Product Manager) or setting (Customer)
page.
1. The System display profile page.
2. User updates or delete profile info and click (save)
button.

36
 3. The System validates input value and display
“successfully updated message”.
4. use case end.

Alternative flow 3.1 user enter wrong input or left blank fields.
i. The System displays Messages that contain “field
cannot be empty or you entered the wrong character”
will be displayed
user repeat
Postcondition Data will be deleted from the database, data inserted into the
database and previously existing product information will be
updated.

Table 4-11. Use case description for manage product

Use case name Manage product

Use case number 011
Description Controlling product.
actor Administrator and Product Manager.
Precondition An ecommerce website should display, both have own account in
the system and they should log into the system and they should be
in the dashboard page.
Normal flow ✓ If one of user select (insert product) link in the manage
product page.
1. The System display inserts form.
2. User fulfill the product information and click on (insert)
button.
3. The System validates input value.
4. The system will display “successfully inserted message”.
5. use case end.

37
 ✓ If one of user select (update product) link in the manage
product page.
1. The System will display products information with
previous information.
2. User edits product information and click on (update)
button.
3. The System validates entered input.
4. The system will display “successfully Updated message”.
5. Use case end.
✓ If one of user select (delete product) link in manage product
page on one product item.
1. The System will display a message that contains” are you
sure you want to delete with yes and no button”.
2. user select (yes) button, system delete the product from
the list and display successfully deleted message.
use case end.
Alternative flow ✓ In case of insert and update
3.1 user enter wrong input or left blank fields.
i. The System displays Messages that contain “field
cannot be empty or you entered the wrong character”
will be displayed
ii. user repeat 2.
✓ In case of delete
2.1 user selects (no) button
the System cancels deleting action
Postcondition Data will be deleted from the database, data inserted into the
database and previously existing product information will be
updated.

38
Table 4-12. Shipping use case description
Use case name Shipping
Use case number 012
Description Shipping is the physical process of transporting
commodities and merchandise goods and cargo in our case
it’s the process of delivering products to customers
Actor Gust, Customer
Precondition Add a product into cart
Normal flow 1. user click on (check out) link on the cart page
2. The system displays a shipping form.
3. user fulfill the information and click on (next) button.
4. The system validates entered input and proceed to the
next phase.
use case end.
4.1 user enters invalid information
Alternative flow i. The System displays Messages that contain “field
cannot be empty or you entered wrong value” will
be displayed.
Post condition Products will be delivered.

Table 4-13. Logout use case description

Use case name Logout
Use case number 013
Description Exiting from the system
actor Customer, Product Manager, and Administrator.
Precondition Login into system
Normal flow 1. user clicks on (log out) button on the home page
2. the system exit user from the system.
Use case end
Alternative flow Nothing
Postcondition Exit.

39
Table 4-14. Feedback use case description
Use case name Feedback
Use case number 014
Description Commenting on the product.
actor Customer.
Precondition Register and login into the system.
Normal flow 1. member customer clicks on (comment) link on home
page.
2. The System display comment form.
3. member customer enters the comment and clicks on
(comment) button.
4. The system validates entered input.
5. The system will display the comment
Use case end
Alternative flow 4.1 user enters wrong input or left blank fields on updating
cart.
1. The System displays Messages that contain “field
cannot be empty or you entered the wrong
character” will be displayed
User repeat 3
Postcondition Seller and users can get feedback about a specific product.

Table 4-15. Rate use case description

Use case name Rate
Use case number 015
Description Determining the value of the product.
actor Customer.
Precondition Register and login into the system.

40
 Normal flow 1. member customer clicks on rate star sign on the
product page.
2. The System stores the rate by calculating the total.
Use case end.
Alternative flow Nothing.
Postcondition Seller and users can get feedback about a specific product.

Table 4-16. Comment use case description

Use case name Give comment
Use case number 016
Description Commenting on the product.
actor Customer.
Precondition Register and login into the system.
Normal flow 6. Customer clicks on (comment) link on home page.
7. The System display comment form.
8. member customer enters the comment and clicks on
(comment) button.
9. The system validates entered input.
10. The system will display the comment
Use case end
Alternative flow 4.1 user enters wrong input or left blank fields on updating
cart.
2. The System displays Messages that contain “field
cannot be empty or you entered the wrong
character” will be displayed
User repeat 3
Postcondition Producer and users can get feedback about a specific
product.

41
Table 4-17. view transportation detail use case description
Use case name View transportation detail
Use case number 017
Description Viewing products detail information
actor Transporter and Product Manager.
Precondition Adulis e-commerce website should display.
Normal flow 5. User clicks on (detail) button on the selected product
on the product page.
6. The System will display the product detail information.
7. User view the detailed information
Use case end.
Alternative flow Nothing.
Post condition Get extra information about products

Table 4-18. Authentication use case description

Use case name Authorization
Use case number 018
Description Authorization is the process of upgrading or downgrading
a user role
Actor Administrator
Precondition A user must have an admin role when logging in
Normal flow 1. The actor is on admin side dashboard
3. Actor selects the user link
4. The system views all users with their respective role.
5. The actor selects a single user
6. The system views the available roles to upgrade or
downgrade
7. The actor selects the desired role
8. The system updates the role for a particular user
The system shows a success message

42
 3.1 There is no user at the moment
Alternative flow iii. The System displays Messages that contain “There is
no user at the moment”

6.1 The admin selects the current role of the user

ii. System displays “that is the current role of the user”
message

Postcondition Users role upgraded or do ungraded

4.1.1.3.Use Case Scenario

A use case scenario, or scenario for short, describes a real-world example of how one or more
people or organizations interact with a system. They describe the steps, events, and/or actions
which occur during the interaction. Use case scenarios can be very detailed, indicating exactly
how someone works with the user interface, or reasonably high-level describing the critical
business actions but not the indicating how they're performed.

Scenario name: Login.

Participating actors: MR. Abebe
Initial assumption: power and connection are available. Also, browser is open.
Normal flow of events:
• Mr. Abebe click on (login) link on home page.
• The System display login page.
• Mr. Abebe fulfils the username and password and then click on
(Login) Button.
• The System validate input value.
• Mr. Abebe has access to his account (logged in).
• End use case.

Alternative flow:

43
 • The System displays a Messages that contain “field cannot be empty or
you entered wrong username or password” will be displayed.

Scenario name: User registration.

Participating actors: Mr. Ahmed
Initial assumption: E-commerce system should be first displayed.
Normal flow of events:
• Mr. Ahmed click on (register) link on home page.
• The System display registration page.
• Mr. Ahmed fulfil the information that system request and click on (register)
button.
• The System validate entered value from user.
• The system Registers Samuel and display Successfully registered message.
• The System display home page.
• Use case end
Alternative flow:
• Mr. Ahmed enters incorrect information and the System displays a Messages
that contain “field cannot be empty or you entered wrong value” will be
displayed.
Scenario name: Update product.
Participating actors: Mr. Kedir.
Initial assumption: Kedir is logged in into the system and on manage page.
Normal flow of events:
• Kedir. click on (edit) link from manage product page on one product
type.
• The System displays previous product information of the selected product
type.
• Mr. Kedir fulfil the update product information and click on (update)
button.
• The System update product information displays successfully updated
message.

44
 • The System display Product page.
• Use case end.

Alternative flow:
• Mr. Kedir don’t fulfill the fields and enter invalid product information;
the System displays a Messages that contain “field cannot be empty or
you entered wrong value” will be displayed.
Scenario name: delete product.
Participating actors: Mr. Jemal.
Initial assumption: Jemal is logged in into the system and on manage page.
Normal flow of events:
• Mr. Jemal click on (delete) link on manage product page on one product
type.
• The System display are you sure you want to delete the product message
with yes and no button.
• Mr. Jemal click on yes button then system delete the product from the
list.
• The System display successfully deleted message and return to previous
page.
Alternative flow:
• Mr. Jemal click no button.
• product remains undeleted.
4.2. Object Model
An object model is a logical interface, software or system that is modeled through the use of
object-oriented techniques. It enables the creation of an architectural software or system model
prior to development or programming. In our system we use object model like class diagram
and data dictionary

45
 4.2.1. Class Diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type
of static structure diagram that describes the structure of a so in our system Ecommerce
(Adulis) there will be class that makes the system like seller, administrator’s, customers etc.

Users
-userId:String
-userFirstName:String
-userLastName:String
Name
-userEmail:String
-userPassword:String
-userRole:String
Name
Name
+login():void
+logout():void

Name
Name Name

Customer ProductManager Administrator

Transporter
Guest -customerId:String -productMaId:String -adminId:String
ProductProvider -transportationType:String
-customerPhoneNumber:String -productMaPhoneNumbe:String -adminPassword:String
--customerCity:String -legalInformation:String -productMaAddress:String -adminPhoneNumber:String
-providerId:String -guestId:String -currentLoction:String --productMaDescription:String
-customerRegion:String
-providerPhoneNumber:String -guestLocation:String -producerLoction:String -transporterId:String
-customerAddress:String
-providerPlace:String -customerlocation:String
1 1 -authonticationCode:String * +register():void
-itemNumber:int *
exchang +authorilize():void
-singlePrice:String assign
+register():void e +deAuthorilize():void
-totalPrice:String
+addToCart():void 1 +order():void +viewReport():void
agreement():void +viewProduct():void +rate():void +updateProfile():void
+viewComment():void +comment():void +deleteProfile():void
+locate():void +register():void
+checkout():void +getTransportationDetail():void
+makePayment():void +assignTransporter():void
+getUserProfile():void +veiwPaymentDetail():void profile
payment
*

profile
1
manage

Name 1 1
*

Order * store
Shipping
*
order
order

-orderId:string Store
Checkout -cartId:String Product
-orderedDate:date
-productId:string -productID:String -storeName:String -productId:String
-transportationType:String Profile
-productName:string -quantity:int -storeLocation:String -productName:String
-paymentId:String -dateAdded:date -productPrice:double
-quantity:int -storeDescription:String 1 * -Location:String
-paymentAmount:double -unitPrice:double -productType:String
-totalCost:double -assingProduct:String -PhoneNumber:String
paymentDate:date -totalPrice:double Stored -productCatagoriy:String
-customerId:string -interest:String
paymentType:String -productImage
-customerName:string
-transportingAddress:string -productAddDate:date
-transportDate:date #addToCart():void -productDescription:String +Updateprfile():void
+pay():void #viewCart():void -productExpDate:date
+notfyPaymentTransaction() +notifyForall():void #removeItem():void #addtoStore():void -productViews:String
+getOrderList():void #viewStore():void -productRate:
+deleteOrder():void #remomeFromStore():void -Comment:String
+updateOrder()void #updateStore():void
+getProduct():void
+addProduct():void
+deleteProduct():void
+updateProduct():void
+uploadProduct():void
+searchProduct():void

Figure 4-6. Class diagram

46
 4.2.2. Data Dictionary

A data dictionary is a file or a set of files that contains a database's metadata. The data
dictionary contains records about other objects in the database, such as data ownership, data
relationships to other objects, and other data. In our Adulis ecommerce system the following
table describe data dictionary. The table 4.19 below is illustrate data dictionary of our system.

Table 4-19. Data dictionary

Table name: Order list
Primary key: order_Id
Description: used to put list of information that related to ordered items

Attributes Data type Data size Constraint Description

orderId String 30 Primary key Unique identification
for ordered item
orderedDate Date Not null Date for ordered item
Productid String 30 Foreign key Unique identification
form product primary
key
ProductName String 30 No null The name of the
ordered item
Quantity Int 20 Not null The amount of the
ordered item
totalCost Double 50 Not null The total amount of
price all ordered item
customerId String 30 Foreign key the identification of
customer that ordered
item
CustomerName String 30 Not null Customer name that
order item
Transportingaddress String 30 Not null The place of item
transported
transportDate String Not null The time to
transporter to
transport
Table name: product Manager list
Primary key: productMaId
Description: used to put list of information producer

47
 Attributes Data type Data size Constraint Description
productMaId String 30 Primary key Unique identification
for product Manager
productMaName String 30 Not null The name of the
product Manager
productMaPassword String 30 Not null Product is register or
not
productMaPhonenumber String 30 No null Phone number of
product Manager
ProductMaAddress String 30 Not null The place of product
Manager
productMaDescription String 50 Not null Information about
product Manager
TransportId String Foreign key Unique identification
to transporter to
transport

Table name: product list

Primary key: producId
Description: used to put list of information related to product
Attributes Data type Data Constraint Description
size
Productid String 30 Primary key Unique identification for
product
producerName String 30 Not null The name of the product
producPrice double 30 Not null Product price
productType String 30 No null The type of the product
productCatagory String 30 Not null The category
productDescription String 50 Not null Information about product
productImage String 50 Not null Image of the product
productAddDate Date Not null Date of the to store
productExpDate Date Not null The expired date of the
product
productView String 30 Not null The product list
productRate Rate Null The acceptance of product
comment String 30 Null Comment about the
product

Table name: customer list

Primary key: customerid

48
Description: used to put list of information that related to customer
Attributes Data type Data Constraint Description
size
customerId String 30 Primary key Unique identification for
product
customerName String 30 Not null The name of the customer
customerPhoneNumber double 30 Not null Phone number of the
customer
customerEmail String 30 No null The email of the customer
customerCity String 30 Not null The place city of the
customer
customerRegion String 50 Not null The place region of the
customer
customerAddress String 50 Not null The customer address

4.3. Dynamic Model

A dynamic model represents the behavior of an object over time. It is used where the object's
behavior is best described as a set of states that occur in a defined sequence. In our system we
use sequence diagram, activity diagram, State diagram.

4.3.1. Sequence Diagram

A Sequence diagram is an interaction diagram that shows how processes operate with one
another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram
shows object interactions arranged in time sequence. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between the objects needed to carry
out the functionality of the scenario so in Adulis Ecommerce website there will be different
process to do specific actions and we include some sequence diagrams to handle these
interactions.

49
50
 Loginpage Loginpage Logged in
Ec database
User <<UI>> <<Control>> <<UI>
1:click login link

2:displaying

3:fill the infio

4:request for
validation
5:validate

5.1:valid
check

5.1.1.valid
(found)

5.1.2:display

5.1.3.display

5.1.2.valid not
5.2.1.desplay inv alid found
username and
password
5.2.2.display
invalid user

Constraint Constraint Constraint Constraint

Constraint

Figure 4-7. Login sequence diagram

51
 Homepage Registration Registration
Ec Database
<<UI>> <<UI>> <<Controller>>
User Constraint Constraint Constraint
1: Click register
Constraint link

2:displaying

3:fill the info

4 request for
validation

5:Validate

5.1:valid

5.1.1.display
success message
5.1.2.display
conform message
5.2.(invalid) display
invalid input
message

5.2.1:display unable
to conform message

Constraint

Figure 4-8. Register Sequence diagram

52
 Dash board Manage
page product Update page Update page
<<UI>> <<UI>> Administrator Ec database
<<UI>> <<controller>>
Admin

1:click manage
product link

2:displaying

3:click update
product link

4:display

5:full fill info

6:requeat for
validation

7:validate

7.1:request for
approval

7.1.1 approve

7.1.1.1:approve
update
7.1.1.2:display
success message
7.1.1.3: display
update message
7.2:display not
approve message
7.3:display not
update message

7.2.1:invalid
7.2.2:display message
invalid message

Constraint
Constraint Constraint Constraint
Constraint Constraint Constraint

Figure 4-9. Update product sequence diagram

53
Constraint

cart page shipping page shipping page payment page payment page
EC Database Object Lifeline
<<UI>> <<UI>> <<controller>> <<UI>> <<controller>>
Gust,
Constraint 1: [click] Constraint Constraint Constraint Constraint Constraint
customer check out Constraint
link

2. Dis play

3.fulfills the
s hipping info

4.Request f or validation

5. validate

5.1 save user

info

5.1.1. Display

5.1.2. f ulf ills the

payment login inf o
5.1.3.request for
validation

5.1.4. validate

5.1.4.1.(valid)
request for user
info

5.1.4.3.found

5.1.4.4. display
5.1.4.5. display warned message
warned money
be with drawn

5.1.4.6. click
confirm button
5.1.4.7.request
for confirmation
5.1.4.8.request
for balance

5.1.4.9.1.
sufficient
5.1.4.9.2. display balance
5.1.4.9.3. display successful
successfully
bought

5.2. display
invalid input
5.2.1. display message
invalid input 5.1.5.Display
message invalid input
message
5.1.5.1.Display
invalid input 5.1.4.3.user not
message 5.1.4.3.user not found
5.1.4.3.4.2. user found
not found

5.1..4.0.
insufficient
balance
5.1.4.1.1.
5.1.4.1.2. display
display insufficient
insufficient balance
balance

Figure 4-10. Checkout sequence diagram

54
 4.3.2. Activity Diagram
Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system in order to perform many
tasks there should be one or more activity to be done. from figures 4.12 to figures 4.14 below
are our system activity diagram

Click login link Fill login form Click login button

Invalid
Error message validation

valid

Admin Home

click
Authontication click register click Product click manage
link link link link

user with
Register form
Association role list Association Insert page

manage
Display error click upgrade or profile
error message fill and click
message downupgrade lik fill for and click Association manage users
save button
register button

fill form
invalid error
validation message
click delete
valid invalid invalid button
Validation validation

valid
Association
Association Association
upgrade and conform
registered add update delete
downgrade
the system send error
Association Association input data admin Association
message
no
decision

yes

invalid Admin click

Admin click valid verify disapprove
Association success fully
approve button button Association
validate
Association

Association Association

Association
Association Association profile
managed
Association
Association

logout

Figure 4-11. Activity diagram for Administrator side

55
 Click login link Fill login form Click login button

Invalid
Error message validation

valid

Producer
Home

Click Manage Click Assing

link Transporter link

click
register transporter
link page

click product
link
click profile
link search by id
Register
Association form
product page Association

error validate error message

fill form message
fill form fill for and click
register button valid

fill info

invalid
Validation
insert update view delete
Association

Insert update delete assingned

registered
display error
error message message

Association
validate Association
Association Association
Association
validate

managed
correctly
profile
managed

logout

Figure 4-12. Producer side activity diagram

56
 go to the
view land page
website URL

view products click login

add product to
register fill login form
cart

fill registration click login

display error
validate validate
message

customer
home page

search

click on a click on the click on a store

click on orders
product notification link name

comment on add products

rate a product view order click on deliver view view store
product to cart

click on update remove click on

order notification contact store

remove product empty cart

fill message
fill form
form

validate validate

precede to
check out

click on send
update order
message

fill delivery form

validate

Activity

Activity

Figure 4-13. Customer and other activity diagram

57
 4.3.3. State Chart Diagram
State chart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
So, the most important purpose of State chart diagram is to model life time of an object from
creation to termination whenever performing different activities there will be some states that
are included in activities so in our project Adulis ecommerce website we have listed below
some states that can be covered during the user interacts with the system. figure below from
figure 4.15 to figure 4.21 describe the state diagram of our system.

Login

Home page
Login page link selected

Login page
prompt insert username and
password

Login

incorrect username and password

Correct username and password

Login Succesfull
logged in Page displayed

Figure 4-14. Login state chart diagram

58
 Register

Any page

Register link

Register page
prompt name ,email,
password ,country city etc

Register

invalid

valid

Figure 4-15. register state diagram

59
 Manage Product

Login Page
prompt username and password

login

invalid

valid

home page

manage product

Manage Product Page

delete product
update product
insert product

Figure 4-16. Manage product state chart diagram

60
 Search

Any page

search icon

Search bar
prompt search text

enter

Search result page

Search result page
not found found
result
No search result
found

Figure 4-17. Search product state chart diagram

61
 comment

product page

select detail link

product detail page

select comment link

comment form
prompot text

select comment button

Invalid input

product detail page

valid input
comment displayed

Figure 4-18.Comment for product state chart diagram

62
 Rate

product page

select detail link

product detail page

select rate icon

product detail page

updated rate displayed

Figure 4-19. Rate State chart diagram

63
 Logout

Any page

Logout

home page

Figure 4-20. logout State chart diagram

64
 CHAPTER FIVE
5. SYSTEM DESIGN
System design is the transformation of the analysis model into a system design model. Design
is process of describing, organizing, and structuring system components at architectural design
level and detailed design level. Adulis E-commerce system design overview is proposed
solution for existing system problem through proposed system. Our proposed system is divided
into different categories in order to the complexity of system when we providing a solution for
the specific problem.

5.1. Design Goals

Design goals are targets for design work. These are typically agreed upon by stakeholder as the
criteria for comparing design alternatives and evaluating design outcomes. The objectives of
design are to model the system with high quality. The design goals are derived from
nonfunctional requirements that means non-functional requirement is the description of the
feature characteristics and attribute of the system as well as any constraints that may limit the
boundary of the proposed system. The Design Goals specify the qualities of the system that
should be achieved and addressed during the design of the system. The following are
illustrative examples of design goals

5.1.1. Performance
The system selects portability compares to performance but not say our system does perform
his task with low performance that annoy every user rather the system performs its operation
without depending specific type of operating system as a result of this users can install the
system any place where ever it needed without both a kind of plate form, they going to use.
5.1.2. Dependability
The Adulis Ecommerce system needs to be highly dependable. The system should be robust
and fault tolerant. Furthermore, as the system is handling sensitive data of the organization,
high emphasis should be given with regards to security, as there are subsystems to be accessed
through web. The proposed system should achieve the following dependability characteristics
in order to resist crash and be available and reliable.

65
 • Robustness: Since the system is a web-based system that mainly uses a menu driven
access there would not be an input problem by the user side. But for the server side
there might be an error during the process of entering a data. In this time the system
will provide an error page and the system will continue without failure or affection.

• Availability: -as long as there is an internet connection the system will be available
always.

• Security: the system should be secured, i.e., not allow unauthorized users to access
the database system.

▪ Reliability: the information provided by the system is as reliable as it is presented

on the web page interface, and this is maintained by the persistent database.

5.1.3. Maintenance

Maintenance: - In time of failure or need modification the system needs to be maintained.

To be maintainable the system should meet the following maintenance criteria.

• Extensibility: - If it is needed to add new functionality to the system, this must be

achieved by only making a separate page and integrate this page with the existing
system.
• Modifiability: - If in the system, some functionality requires to be modified, this
modification must be done specifically to that function or page without affecting the
overall system organization.

5.1.4. End user

The system’s end users are classified in to two main categories, these are:
• Profession user (Administrator): He/she will take technical as well as supportive
trainings in order to help the layman users when problems arise.
• Layman (Customer, Product Manager): A user who has some basic computer
knowledge, they can operate the system with simple training and by the help of user
documentation.

66
 5.1.5. Priorities of Design Goal
Functionality vs Usability
The system favors usability compared to functionality yet it doesn’t mean that the system loses
its proper functionality. rather the developing team will endeavor to maintain the basic
requirements of the system along with high usability. The system will avoid lavish
functionalities, which are not a must for the system’s existence, for the sake of encouraging
basic system utilization
Performance vs portability
The system selects portability compares to performance but not say our system does perform
his task with low performance that annoy every user rather the system performs its operation
without depending specific type of operating system as a result of this users can install the
system any place where ever it needed without bother a kind of plate form, they going to use.
Security vs Usability
Possible have lots of reason for selecting security instead of usability but again our system
considers usability besides security. Relating security issues our system will drown line for
each user which functionality of the system need to access by authenticate finally, record each
users of the systems’ information including the task they have done on that specific date, also
securing data during transfer is one of task our system handles additional to others security
matter.
5.2. Current System Architecture
The current system uses three tier system architecture. Three-tier architecture allows any one
of the three tiers to be upgraded or replaced independently. The three-tier architecture includes
three tiers: top tier, middle tier and third tier.

The top tier includes a user interface where user services such as session, text input, and dialog
and display management reside. The middle tier provides process management services such
as process development, process monitoring and process resourcing that are shared by the
multiple applications. The third tier provides database management functionality. The data
management component ensures that the data is consistent throughout the distributed
environment, the centralized process logic in this architecture, which makes administration
easier by localizing the system functionality, is placed on the middle tier.

67
 Client Client Client

Application process Application process Application process

Database Database Database

Figure 5-1. Current system architecture

5.3. Proposed System Architecture

Our proposed system is consisting of 3-tier architecture namely presentation layer, business
logic layer, and data layer. The presentation layer is client layer and topmost layer of the
application. This is the layer we see when we use this system. It is the interface to our
system which takes information from the user. The main functionality of this layer is to
communicate with the application layer. This layer passes the information which given in
terms of keyboard action and mouse click to the application layer. Example when user want
to login into the system first see two text box and login button to enter user name and
password and click on login. Business logic layer it is application layer which interacts
with data layer and sends information retrieved from database toward to presentation

68
 layer.it act as the mediator between presentation layer and data layer. From above example
once, the user clicks on login button application layer interact with the database and send
information towards to presentation layer. The third one is data layer which used to store
data entered by the user. In general client of our system use browser to access the system
using the internet.in this case when the user enters input and takes certain action application
server process client request to interacting with the database server. Figure 5.2 below is
proposed system architecture.

Figure 5-2. Proposed system architecture

5.3.1. Subsystem Decomposition and Description

Subsystem decomposition is the process of dividing the system in to manageable subsystems

from the analysis model of the proposed system. The goal of the system decomposition is to
reduce the complexity of design model and to distribute the class of the system in to large scale
and cohesive components. Components are generally units of computation or data stores in the
system. A component has a name, which is generally chosen to represent the role of component
or the function it performs. The different components of a system are likely to interact while
the system is in operation to provide the service expected of the system.in our system the
following subcomponent is available.

69
 ✓ Administrator subsystem-- responsible for handling action that administrator
performs.

• Manage product.
• Manage producer.
• Manage customer.
• Manage profile.
• Authorization
• Login.
• Logout.
• View notification

✓ Gust subsystem- perform for some activity that System available the viewer.
• Register
• Search product
• View product
• Add to cart
✓ Customer subsystem- responsible for handling action that Customer perform.
• View notification
• Login
• Order
• Search product
• View product detail.
• Add to cart
• Edit cart
• Payment
✓ Product Manager subsystem - responsible for the system:
• View notification
• Register.
• Login.
• Logout.
• Agreement
70
 • Manage profile.
• Manage product.
• View histories.
✓ Transporter subsystem - responsible for payment and transport activity.
• View transport detail
• Shipping detail
• Payment
Product provider: responsible for provide product and agreement with product manager
• Agreement
the following figure 5.3 is show subsystem decomposition of our system

71
 Adulis(E commerce subsystem)

Administrator
subsystem Customer

View
Login Authorilization
Login product
detail
Manage
Manage
product
product Add to cart
View
notification
Manage View
customer notification
Edit cart
Order
Manage
Logout
profile Payment
Search
product

Product
provider
connection
subsystem

Agreement
Connection
database

Guest
Product Manager Pransporter

Manage
Search
Register Login histories view
product
transport
detail

Manage
Register shipping
product
detail
view
Add to cart
product
View
Logout
notification
payment

Agreement

Figure 5-3. Subsystem Decomposition

5.3.2. Hardware/Software Mapping

Deployment diagram depicts a static view of the run-time configuration of processing nodes
and the components that run on those nodes. In other words, deployment diagrams show the
hardware for your system, the software that is installed on that hardware, and the middleware

72
used to connect the disparate machines to one another. You want to create a deployment
diagram for applications that are deployed to several machines. It also shows how the
software and the hardware components work together. Deployment diagram used to show
the hardware of the system, the software that is installed in the hardware and also the
middleware that is used to connect the disparate machines to one and other.it also shows how
the software and hardware components of the system work together. The figure 5.4 below is
shows the deployment diagram of our system.

<<Device>>
:Application Server
authoraliz
ation
<<Device>> view <<Device>>
:Browser notification :Database server

login
Admin
manage
product Security
Query
Product
logout
Manager

register

search
Customer http
product

order

add to
Guest
cart

Feedback

view
Transporter
product moogo database

Payment
Product
Provider view
transport
shipping
detail

Agreement

Figure 5-4. Deployment diagram

5.3.3. Detailed Class Diagram
Detail class diagram is class diagram that include attributes, methods, attribute data types,
visibility of attributes and methods, inheritance, association, aggregation, composition,
dependency, and municipality (cardinality and optimality). The following figure, uses the UML

73
class diagram to specify attributes and operations with their visibility information. The following
table shows the detail class diagram of our system

Table 5-1. Detail class

Class name Attribute Attrib Attribu methods Return Meth
ute te type ods
type Visibilit Visib
y ility
Users • userId String - login() Void +
• String - logout() void +
String -
• userFirstName
String -
• userLastName String -
• userEmail string -
• userPassword
• userRole
Product • productMaId String - updateProfile() Void +
• productMaPhone int - deleteProfile() Void +
Manager
-
• productMaAddres String register() Void +
-
s String assignTransporter() Void +
-
• productMaDescri String veiwPaymentDetail() void +
ption
• transporterId
Guest • guestId String - register() Void +
• guestLocation String - addToCart() Void +
viewProduct() Void +
viewComment() void +
Customer • customerId String - order() Void +
• customerPhone Int - rate() Void +
• customerCity String - comment() Void +
• customerRegion String - checkout() Void +
• customerAddress String - makePayment() Void +

Transporter • transportationTyp String - locate() Void +

e String - getTransportationDe Void +
• legalInformation String - tail() Void +
• currentLoction String - getUserProfile()
• producerLoction String -
• customerlocation String -
• authonticationCod
e
Product • productMaId: String - updateProfile() Void +
manager • productMaPhone int - deleteProfile() Void +
String - register() Void +

74
 • productMaAddres String - assignTransporter() Void +
s String - veiwPaymentDetail() Void +
• productMaDescri
ption
• transporterId
Administrator • adminId String - register() Void +
• adminPassword String - authorilize() Void +
• adminPhone Int - deAuthorilize() Void +
viewReport() Void +
Checkout • transportationTyp String - pay() Void +
e: String - notfyPaymentTransa void +
• paymentId:String Double - ction()
• paymentAmount:d Date -
ouble String -
• paymentDate:dat
e
• paymentType
Order • orderId String - notifyForall() Void +
• orderedDate Date - getOrderList() Void +
deleteOrder()
• productId String - Void +
updateOrder()
• productName String - void +
• quantity Int -
• totalCost double -
• customerId string -
• customerName string -
• transportingAddre string -
ss date -
• transportDate
Shipping • cartId:String String - addToCart() Void #
• productID:String String - viewCart() Void #
void
• quantity:int Int - removeItem() #
• dateAdded:date Date -
• unitPrice:double double -
• totalPrice:double double -
Store • storeName String - addtoStore() Void #
• storeLocation String - viewStore() Void #
• storeDescription String - remomeFromStore() Void #
• assingProduct String - updateStore() Void #
• productId String - getProduct() Void +
• productName String - addProduct() Void +
deleteProduct() Void
• productPrice Double - +
updateProduct() Void
• productType String - uploadProduct() void
+
• productCatagoriy String - searchProduct() void +
• productImage Date - +
• productAddDate -
• productDescriptio String -
n Date -

75
 • productExpDate String -
• productViews - -
• productRate string -
• comment
Profile • location String - Updateprfile() Void +
• phoneNumber String -
• interest String -

5.3.4. Persistent Data Management

Persistence modeling is used to communicate the design of the database, usually the data
base to both the users and the developers. It is also used to describe the persistence data
aspect of the system. The following tables indicate the persistence data management of the
system.

76
 Users
-userId:String Users<<Table>>
-userFirstName:String userId<<primary key)
-userLastName:String
-userEmail:String userFirstName
-userPassword:String userLastName
-userRole:String
userEmail
userPassword
+login():void userRolr
+logout():void

Order<<Table>>
Order
Product<<Table>>
-orderId:string orderId (Primary key) Product
-orderedDate:date productId (primary key)
orderedDate -productId:String
-productId:string productName
Name -productName:String
-productName:string productId (foreign key) -productPrice:double
-quantity:int productPrice
-productType:String
-totalCost:double productName -productCatagoriy:String Name productType
-customerId:string
-productImage
-customerName:string quantity
-productAddDate:date productCatagoriy
-transportingAddress:string
totalCost -productDescription:String
-transportDate:date productImage
-productExpDate:date
+notifyForall():void customerId (foreign key) -productViews:String
productAddDate
+getOrderList():void -productRate:
+deleteOrder():void customerName -Comment:String productDescription
+updateOrder()void
transportingAddress +getProduct():void productExpDate
transportDate +addProduct():void
+deleteProduct():void productViews
+updateProduct():void productRate
+uploadProduct():void
+searchProduct():void Comment

Customer
Customer<<Table>>
-customerId::String
-customerName:String Name customerId (primary key)
-customerPhoneNumber:String Transporter<<Table>>
-customerEmail:String customerName Transporter
-customerCity:String -transporterid:String transporterid (primary key)
customerPhoneNumber
-customerRegion:String -transportationType:String Name transportationType
-customerAddress:String customerEmail -legalInformation:String
-currentLoction:String legalInformation
+order():void customerCity -producerLoction:String
+rate():void -customerlocation:String currentLoction
customerRegion
+comment():void -authonticationCode:String
customerlocation
+checkout():void customerAddress
+makePayment():void producerLoction
+locate():void
+getTransportationDetail authonticationCode
():void
+getUserProfile():void

Gust Gust<<Table>> Administrator

-gustName:String Name -adminId:String Administretor<<Table>>

-gustId:String -adminName:String Name
gustName
-gustLocation:String -admiEmail:String adminId (primary key)
Association -adminPassword:String
gustId (primary key) -adminPhoneNumber:String adminName

+register():void adminEmail
+addToCart():void gustLocation
+viewProduct():void +registerProducer():void
adminPassword
+viewComment():void +registerTransporter():void
+authorilize():void adminPhoneNumber
+deAuthorilize():void
+viewReport():void

77
 Store ProductManager
Name Store<<Table>>
-storeName:String -productMaId:String ProductManager <<Table>>
-storeLocation:String storeName -productMaName:String Name
-storeDescription:String -productMaPassword:String productMaId(primary key)
-assingProduct:String storeLaction -productMaPhoneNumbe:String
-productMaAddress:String productMaName
--productMaDescription:String
storeDescrioption productMaPassword
-transporterId:String
#addtoStore():void
#viewStore():void productMaPhoneNumbe
#remomeFromStore():void assingProduct +updateProfile():void productMaAddress
#updateStore():void +deleteProfile():void
+register():void productMaDescription
+assignTransporter():void
transporterId(foreign key)
+veiwPaymentDetail():void

Shipping
-cartId:String
Name shipping<<Table>>
-productID:String
-quantity:int cartId(primary key)
Profile<<Table>>
-dateAdded:date productId(foreign key) Profile
-unitPrice:double
quality -location:String location
-totalPrice:double
dateAdded -phoneNumber:String
#addToCart():void -interest:String phoneNumber
#viewCart():void unitPrice
-updateProfile():void
#removeItem():void totalPrice interest

ProductProvider<<Table>>
CheckOut<<Table>>
ProductProvider
CheckOut
paymentId(primary key) providerId(primary key)
-transportationType:String -providerId:String
-paymentid:String transportationType providerPhone
-providerPhone:String
-paymentAmount:String -providerPlace:String
-paymentDate:String paymentAmount providerPlace
-itemNumber:int
-paymentType:String -singlePrice:double
paymentDate itemNumber
-totalPrice:double
+pay():void paymentType +Agreement():void singlePrice
+notfyPaymentTransaction():void
totalPrice

Figure 5-5. Persistent diagram

5.3.5. Access Control and Security

In our system, different actors have access to different information and data. Access control
and security specifies what the user can access or what cannot perform by some users. This
access control is verified by username and password. System admin represents an authenticated
user. The proposed system follows multi user system. In multi user system, different actors
have access to different functionality and data. Then it must be having: -

➢ Confidentiality: Only authorized person can see the information. Private data is kept
private; personal privacy is respected.

➢ Integrity: There are limits on who can change the data in this system.

➢ Availability: The system is available at all times to authorized users.

78
 Table 5-2. Access Control and Security
Operation
s

Actor Account Order Register Store Product

Admin CRUD ---- CRUD -R-- -R--

Product Manager C-U- -R-D CR-- CRUD CRUD

Customer C-U- C-U- ---- ---- -R--

Gust C--- C-U- C--- ---- -R--

Transporter C-U- -R-- ---- ---- ----

Product provider ---- ---- ---- ---- ----

5.4. Packages
package is an organized and functionality-based set of related interfaces and classes. Packages
organize classes that belong to the same category or provide similar functionality. In our
system we category into database management package, report management package,
notification management package, account management package, security management
package.

Database management package

The database subsystem will be implemented by relational database management system
which is used to store the persistent data.

Report management package

It is a subsystem that helps administrator are the overall status the information the system
and producer are needs to knows the overall information about product, customer, viewer
transporter and ordered status of the system.

Notification management package

It is a sub system that helps communicates between each other and provides notification
service.

79
Account management package
It is a subsystem that helps administrator to manage user account.

Security management package

It is a subsystem that helps to secure the proposed system.
The following diagram is shows the package diagram of our system

Account
managment

Include

Report
managment

Include

Database
Managment

Notification
Managment

Include

Security
Managment

Include

Figure 5-6. Package diagram

5.5. Algorithm Design

Algorithms are designed to show the flow of programs in the system. They are semantic driven
rather than syntax driven. That means, the rule of syntax is not respected as other programming
language but it has a complete meaning as that of syntax-based programming language. In

80
addition, Algorithms show the flow and steps of logic in each function. This design part is
important in the coding part of implementation. Some of the algorithms are listed below.
Example: -
o Login
• Home page displayed.
• User click on sign in link
• System display sign in page.
• User enter user email and password.
• If user email and password is correct, then
• If user is customer, then system display customer page.
• Else if user is product manager, then system display producer page.
• Else if user is admin, then system display admin page.
• Else user email and password is not correct, then system display error
message and redisplay login page.
➢ Create account
• Home page displayed.
• User click on sign up
• System display sign up page.
• User fulfill its information.
• If entered information is correct, then
• If user email is verified, then user information registered correctly.
• Else user email is not verified, then system display your email is not verified
message.
• Else user information is not correct, then system display your input is
incorrect message.

5.6. User Interface Design

User interface design (UI) or user interface engineering is the design of user interfaces for
machines and software, such as computers, home appliances, mobile devices, and other
electronic devices, with the focus on maximizing the user experience. The goal of user interface
design is to make the user's interaction as simple and efficient as possible, in terms of

81
accomplishing user goals (user-centered design) so in our project Adulis ecommerce system
we have designed user interfaces that increase the user experience.

Figure 5-7. Web home page UI

The above UI describes the home page for any customers who want to visit Adulis ecommerce
system using wide screen devices in order to view, buy and explore products.
.

82
Figure 5-8. Mobile register UI
The above UI describes the registration page for new customers who want to be register in
Adulis ecommerce system using small screen devices and who want to get better service which
is difference from the unregistered customers so in this UI user is only obliged to enter the
information on the above fields and to click the register button.

83
REFERENCES
BOOKS:
Ermiyas Birhanu (MSc.), Worku Muluye (MSc.) Zerihun Mulugeta (MSc.) W. M. (2018).
WKU Reviewed Project Guideline Version 4 (2). wolkite: wku.
Gary_P._Schneider. (2008). Electronic_Commerce_Seventh_. United States: Bringbritish
(Systems Analysis II, Domain Modeling,)
(System Analysis and Design Object Oriented Approach)
(The_Object_Primer_-_Agile_Model-Driven_Development_with_UML_2.0)
WEB SITE:
amazon.com. (1999, 23 12). Retrieved from Amazon : https//.AWS.amazon.com/architecture
amazon. (2008, 7 08). Retrieved from amazon.con: https://www.investopedia.com
(The Application Developer’s Guide to Object Orientation and the UML. , 2001)
( http://www.agilemodeling.com/artifacts/classDiagram.htm)
( http://en.wikipedia.org/wiki/Sequence_diagram )

84
APPENDICES A

Enter new shipping form:

Tell us about your business for in amazon

85
86