A

Project Report
on

“ONLINE SHOPPING SYSTEM”

Submitted by
PATHAN SOHA WAJED
PATIL PRITI RAVIKIRAN
DESHMUKH PRADYUMNA S.

Guided by
Prof.N.G.Dharashive

Submitted to
Department of Computer Science and Engineering

M. S. Bidve Engineering College, Latur

Academic Year2019-2020
 CERTIFICATE

This is to certified that Pathan Soha Wajed, Patil Priti Ravikian, Deshmukh Pradyumna
S. has successfully completed the project : “Online Shopping System” for the Partial
fulfillment of the Degree in the Computer Science and Engineering department as prescribed
by the Swami RamanandTeerthMarathwada university, Nanded during academic year 2019-
20.

Prof.N.G.Dharashive Prof.Tandle S.R. Prof. Khatod N.B.

Guide H.O..D. Principal
 Acknowledgement

We are profoundly grateful to Prof.N.G.Dharashive Sir for his guidance and continuous
encouragement throughout to see that this project rights its target since its commencement to
its completion.

We would like to express deepest appreciation towards Prof.Khatod Sir, Principal, MS

Bidve College of Engineering, Prof.Tandle S.R Sir, Head of Department of Computer
Engineering whose invaluable guidance supported us in completing this project.

At last we must express our sincere heartfelt gratitude to all the staff members of
Computer Engineering Department who helped us directly or indirectly during this course of
work.
 ABSTRACT

The hassle of queues in shops, human errors in manually generated bills and the
wastage of time in the packaging of products after shopping creates inconvenience
to shoppers and eventually leads to lower customer satisfaction levels. With the de-
velopment of digital technology online payments can be made for various purposes.
This paper discusses the design of an online shopping system where the generate
automatic E-billing system including all taxes. After completion of shopping, cus-
tomers can exit the shop with their bills deducted automatically from their e-Wallet. A
Web Application is hosted on an AWS EC2 instance to allow customers to keep
track of their transactions. The system is connected to inbuilt Wi-Fi to communicate
with MySQL instance which stores the inventory of the retail store along with the
prices of the products. It also stores the current items in the cart and the history of
previous transactions of every customer.
 Table of content

1 INTRODUCTION 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problem Definition and Objectives . . . . . . . . . . . . . . . . . . 2
1.3.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . 2
1.3.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Project Scope and Limitation . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Methodologies for Problem Solving . . . . . . . . . . . . . . . . . 3

2 LITERATURE SURVEY 5

3 SOFTWARE REQUIREMENTS SPECIFICATION 6

3.1 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . 6
3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 System Feature 1(Functional Requirement). . . . . . . . . . 6
3.3 External Interface Requirements . . . . . . . . . . . . . . . . . . . 6
3.3.1 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . 7
3.3.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . 7
3.3.4 Communication Interfaces . . . . . . . . . . . . . . . . . . 7
3.4 Nonfunctional Requirements . . . . . . . . . . . . . . . . . . . . . 7
3.4.1 Performance Requirements . . . . . . . . . . . . . . . . . . 7
3.4.2 Safety Requirements . . . . . . . . . . . . . . . . . . . . . 7
 3.4.3 Security Requirements . . . . . . . . . . . . . . . . . . . . 7
3.4.4 Software Quality Attributes . . . . . . . . . . . . . . . . . 8
3.5 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1 Database Requirements . . . . . . . . . . . . . . . . . . . . 8
3.5.2 Software Requirements(Platform Choice) . . . . . . . . . . 8
3.5.3 Hardware Requirements . . . . . . . . . . . . . . . . . . . 8
3.6 Analysis Models: SDLC Model to be applied . . . . . . . . . . . . 9
3.7 System Implementation Plan . . . . . . . . . . . . . . . . . . . . . 11
3.7.1 Timeline chart . . . . . . . . . . . . . . . . . . . . . . . . 11

4 System Design 14
4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Data Flow Diagrams: . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Level 0 data flow diagram . . . . . . . . . . . . . . . . . . 15
4.3 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Use case Diagram . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 Activity Diagram: . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.4 Component Diagram . . . . . . . . . . . . . . . . . . . . . 22
4.3.5 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . 23

5 Project Plan 24
5.1 Project Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1 Reconciled Estimates . . . . . . . . . . . . . . . . . . . . . 24
5.1.2 Project Resources . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Risk Identification . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 Project task set . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.2 Task network . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.3 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.4 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Team Organization . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1 Team structure . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2 Management reporting and communication . . . . . . . . . 29
6 Project Implementation 30
6.1 Overview of Project Modules . . . . . . . . . . . . . . . . . . . . . 30
6.2 Tools and Technologies Used . . . . . . . . . . . . . . . . . . . . . 30
6.2.1 Technology Description . . . . . . . . . . . . . . . . . . . 30
6.2.2 Hardware Specifications . . . . . . . . . . . . . . . . . . . 31
6.2.3 Software Specifications . . . . . . . . . . . . . . . . . . . . 31
6.3 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3.1 AES Encryption Algorithm . . . . . . . . . . . . . . . . . 31

7 Software Testing 33
7.1 Types Of Testings . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.1 Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.2 Integration testing . . . . . . . . . . . . . . . . . . . . . . 33
7.1.3 Functional test . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.4 System Test . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1.5 White Box Testing . . . . . . . . . . . . . . . . . . . . . . 34
7.1.6 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . 34
7.1.7 Unit Testing: . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1.8 Integration Testing . . . . . . . . . . . . . . . . . . . . . . 35
7.1.9 Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Test cases and Test Results . . . . . . . . . . . . . . . . . . . . . . 35

8 Results 39
8.1 Screen Shots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9 CONCLUSION 52
9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

REFERENCES 52
 List of Figures

3.1 Gannt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Gannt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 DFD Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 DFD Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 DFD Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 USECASE .............................. 18
4.6 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.7 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 Task network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Team structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8.1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.2 Admin Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3 Admin Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.4 All Product Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.5 View Product Review Page . . . . . . . . . . . . . . . . . . . . . . 43
8.6 View individual product Page . . . . . . . . . . . . . . . . . . . . . 44
8.7 View review sentiment Page . . . . . . . . . . . . . . . . . . . . . 45
8.8 User Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.9 Login Successfully Page . . . . . . . . . . . . . . . . . . . . . . . 47
8.10 User Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.11 Search Product Page . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.12 View all products Page . . . . . . . . . . . . . . . . . . . . . . . . 50
 8.13 Generate Bills Page . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 1

INTRODUCTION

1.1 Overview

This paper proposes an E-Billing system on the basis of an E-Invoice Framework. The E-
Invoice Framework is an e-invoice solution concentrating on automatically issuing e-
invoices, centralized managing e-invoices and providing taxation services. Thus, the
efficiency of taxation could be great improved and the labor of taxation could be obviously
reduced. Compared with taxpayer-oriented taxation systems, the E- Billing Framework can
firmly support data-oriented taxation systems, which are especially tailored for online
shopping environment.

1.2 Motivation

The users uses MS Excel, and maintains their product list, customer list, and prints the
invoice, however it is not possible them to share the data from multiple system in multi user
environment, there is lot of duplicate work, and chance of mistake. When the product price
are changed they need to update each and every excel file. There is no option to find and
print previous saved invoice.

1.3 Problem Definition and Objectives

1.3.1 Problem Definition

The waiting times in billing counters of shops and malls have been increasing, given the
growth in human population and personal needs. To build and implement Automated Billing
System web application for online shopping.
1.3.2 Objectives

To provide automatic billing system

To implement for online shopping system

To provide security using encryption algorithm

1.4 Project Scope and Limitation

1.4.1 Project Scope

This system used for automatic e-billing system for online shopping. This

system support online transaction.

1.4.2 Limitations

Need internet connection

1.5 Methodologies for Problem Solving

Let us consider S as a system for Online Shopping system.

S=
INPUT:
Identify the inputs
F= f1, f2, f3 ....., FN— F as set of functions to execute commands.
I= i1, i2, i3—I sets of inputs to the function set
O= o1, o2, o3.—O Set of outputs from the function sets,
S=I,F,O
I = user demand
O = Output i.e. bill
F = Functions implemented to get the output
Space Complexity:
The space complexity depends on Presentation and visualization of discovered pat-terns.
More the storage of data more is the space complexity.
Time Complexity:
Check No. of patterns available in the datasets= n

Department of Computer Engineering 2019-20

2
If (n(1)) then retrieving of information can be time consuming. So the time com-plexity of this
algorithm is O (nˆn).
= Failures and Success conditions.
Failures:
1. Huge database can lead to more time consumption to get the information.
2. Hardware failure.
3. Software failure.
Success:
1. Search the required information from available in Datasets.
2. User gets result very fast according to their needs.

Department of Computer Engineering 2019-20

3
Automatic Approach for E-Billing System for Online Application

Chapter 2

LITERATURE SURVEY

In this section, we briefly review the related work on Online shopping system and their
different techniques.

Electronic Invoicing has been defined as the sending or making available of an in-voice and
its subsequent processing and storage, wholly by electronic means [4]. In e-commerce,
invoice is one of the business documents that are most often ex-changed electronically
between transaction parties[5]. At present, e-invoice is at the stage of applying and spreading
in EU, South America and some nations of North America[6]. For example, Kaliontzoglou
proposed an open invoice system named invoke in 2006, based on XML, XML cryptography
and Web Services. The system was established on the basis of trusted third party-provided
PKI to seek se-curity and authentication supports[7]. Spanic proposed an invoice system
providing multi-services to different users in 2011. The system can transfer e-invoices among
large enterprises through EDI of their ERPs, and provide related web services to SMEs(Small
and Medium Enterprises) [8]. Humski proposed an FER e-invoice sys-tem in 2012, which
owes an extensible and open architecture of e-invoice imple-mentation [9]. The above-
mentioned and other e-invoice solutions pay attention to technical details, such as information
security, consumer service and system expan-sibility. This paper, aims at the improvement of
taxation systems to focuses more on direct tax-related data (e-invoice data) than taxpayers. In
order to achieve this target, the E-Invoice Framework is introduced.

Department of Computer Engineering 2019-20

4
Automatic Approach for E-Billing System for Online Application

Chapter 3

SOFTWARE REQUIREMENTS SPECIFICATION

3.1 Assumptions and Dependencies

User must know English Language. The

device has a 64 bit architecture.

The User and the device on which the app is running must be indoors.

A particular institution when required may approach our team and we can pro-vide help
for setting an indoor map. Hence, the must provide a blue print or plans of the building.

3.2 Functional Requirements

3.2.1 System Feature 1(Functional Requirement).

1. Here we propose a online shopping system.

2. We provide payment security.

3.3 External Interface Requirements

3.3.1 User Interfaces

Home page
User and Admin Login Page
Passwords Checking Page Transaction Page
View Transaction Page.

Department of Computer Engineering 2019-20

5
Shopping Page.
Result Page

3.3.2 Hardware Interfaces

The entire software requires a completely equipped computer system including mon-itor,
keyboard, and other input output devices.

3.3.3 Software Interfaces

The system can use Microsoft as the operating system platform. System also makes use of
certain GUI tools. To run this application we need JDK 1.8 and above as java platform and
Apache tomcat as server. To store data we need MySQL database.

3.3.4 Communication Interfaces

Communication using Java and servlet APIs

3.4 Nonfunctional Requirements

3.4.1 Performance Requirements

The performance of the system lies in the way it is handled. Every user must be given proper
guidance regarding how to use the system. The other factor which affects the performance is
the absence of any of the suggested requirements.

3.4.2 Safety Requirements

To ensure the safety of the system, perform regular monitoring of the system so as to trace the
proper working of the system. An authenticated user is only able to access system.

3.4.3 Security Requirements

Any unauthorized user should be prevented from accessing the system. Password
authentication can be introduced.

Department of Computer Engineering 2019-20

6
3.4.4 Software Quality Attributes

Accuracy: -

The level of accuracy in the proposed system will be higher. All operation would be done
correctly and it ensures that whatever information is coming from the center is accurate.
Result is organic results.
Reliability: -

The reliability of the proposed system will be high due to the above stated reasons. The reason
for the increased reliability of the system is that now there would be proper storage of
information and Proper online shopping system model.

3.5 System Requirements

3.5.1 Database Requirements

MySQL Database

3.5.2 Software Requirements(Platform Choice)

Operating System - Windows

Application Server - Apache Tomcat
Front End - HTML, JDK 1.8, JSP Scripts
- JavaScript.
Server side Script - Java Server Pages.
Database - My SQL 5.0
IDE - Eclipse

3.5.3 Hardware Requirements

Processor - Pentium –III

Speed - 1.1 GHz
RAM - 256 MB(min)
Hard Disk - 20 GB
Floppy Drive - 1.44 MB
Key Board - Standard Windows Keyboard

Department of Computer Engineering 2019-20

7
 Mouse - Two or Three Button Mouse
Monitor - SVGA

3.6 Analysis Models: SDLC Model to be applied

The Waterfall Model is sequential design process, often used in Software develop-ment
processes, where progress is seen as flowing steadily download through the phase of
conception, Initiation, Analysis, Design, Construction, Testing, Produc-tion/Implementation
and Maintenance. This Model is also called as the classic Life cycle model as it suggests a
systematic sequential approach to software develop-ments. This one of the oldest model
followed in software engineering. The process begins with the communication phase where
the customer specifies the requirements and then progress through other phases like planning,
modeling, construction and deployment of the software.

There are 5 Phase of water fall model:

1. COMMUNICATION
In communication phase the major task performed is requirement gathering which helps in
finding out exact need of customer. Once all the needs of the customer are gathered the next
step is planning.

Department of Computer Engineering 2019-20

8
2. PLANNING
In planning major activities like planning for schedule, keeping tracks on the pro-cesses and
the estimation related to the project are done. Planning is even used to find the types of risks
involved throughout the projects. Planning describes how technical tasks are going to take
place and what resources are needed and how to use them.

3. MODELING
This is one the important phases as the architecture of the system is designed in this phase.
Analysis is carried out and depending on the analysis a software model is designed. Different
models for developing software are created depending on the requirements gathered in the
first phase and the planning done in the second phase.

4. CONSTRUCTION
The actual coding of the software is done in this phase. This coding is done on the basis of the
model designed in the modeling phase. So in this phase software is actually developed and
tested.

5. DEPLOYMENT
In this last phase the product is actually rolled out or delivered installed at customer’s end and
support is given if required. A feedback is taken from the customer to ensure the quality of the
product. From the last two decades Waterfall model has come under lot of criticism due to its
efficiency issues. So let’s discuss the advantages and disadvantages of waterfall model.

Department of Computer Engineering 2019-20 9

3.7 System Implementation Plan

Table 3.1: System Implementation Plan

3.7.1 Timeline chart

Department of Computer Engineering 2019-20 10

 Figure 3.1: Gannt Chart

Department of Computer Engineering 2019-20 11

 Figure 3.2: Gannt Chart

Department of Computer Engineering 2019-20 12

Automatic Approach for E-Billing System for Online Application

Chapter 4

System Design

4.1 System Architecture

This project is made for one of the shopping systems, presently they issue their client
handwritten invoice and they enter details in manual register. And maintain MS Ex-cel file for
product rate. They want computerization of their manual invoice and bill generation process.

There is no security; anybody can access any report and sensitive data, also no re-ports to find
out the sales volume, stock list, and summary report. This E-Billing and invoicing system is
used to overcome the entire problem which they are facing currently, and making complete
atomization of manual billing including all taxes and invoicing system.

Department of Computer Engineering 2019-20 13

 Figure 4.1: System Architecture

4.2 Data Flow Diagrams:

4.2.1 Level 0 data flow diagram

1.The DFD is also called as bubble chart. It is a simple graphical formalism that canbe used to
represent a system in terms of input data to the system, various pro-cessing carried out on this
data, and the output data is generated by this system.
2. The data flow diagram (DFD) is one of the most important modeling tools. It is used to
model the system components. These components are the system process, the data used by the
process, an external entity that interacts with the system and the information ows in the
system.
3. Figure 4.1 shows level 0 DFD which shows how the information moves through the system
and how it is modified by a series of transformations. It is a graphical technique that depicts
information ow and the transformations that are applied as data moves from input to output.

Department of Computer Engineering 2019-20 14

 Figure 4.2: DFD Level 0

Figure 4.3: DFD Level 1

Department of Computer Engineering 2019-20 15

 Figure 4.4: DFD Level 2

Department of Computer Engineering 2019-20 16

4.3 UML Diagrams

4.3.1 Use case Diagram

A use case diagram is a graphical representation of a user’s interaction with the system and
depicting the specifications of a use case. A use case diagram can show the different types of
users of a system and the various ways in which they interact with the system. Use case
diagrams are used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. So when a system is analyzed
to gather its functionality use cases are prepared and actors are identified. The purposes of use
case diagrams can be as follows:
Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the system. Show
the interaction among the actors.

Figure 4.5: USE CASE

Department of Computer Engineering 2019-20 17

4.3.2 Activity Diagram:

Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Mod-eling Language,
activity diagrams are intended to model both computational and organizational processes (i.e.
workflows). Activity diagrams show the overall flow of control. Activity diagrams are
constructed from a limited number of shapes, con-nected with arrows. The most important
shape types:
Rounded rectangles represent actions;
Diamonds represent decisions;
Bars represent the start (split) or end (join) of concurrent activities; A black cir-cle
represents the start (initial state) of the workflow;
An encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent the order in which activi-ties happen.
Hence they can be regarded as a form of flowchart. Typical flowchart techniques lack
constructs for ex-pressing concurrency. However, the join and split symbols in activity
diagrams only resolve this for simple cases; the meaning of the model is not clear when they
are arbitrarily combined with decisions or loops.

Department of Computer Engineering 2019-20 18

 Figure 4.6: Activity Diagram

Department of Computer Engineering 2019-20 19

4.3.3 Class Diagram

Figure 4.7: Class Diagram

Department of Computer Engineering 2019-20 20

4.3.4 Component Diagram

A Component Diagram displays the structural relationship of components of a soft-ware

system. These are mostly used when working with complex systems that have many
components. Components communicate with each other using interfaces. The interfaces are
linked using connectors.

Figure 4.8: Component Diagram

Department of Computer Engineering 2019-20 21

4.3.5 Deployment Diagram

Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed. So deployment diagrams are used to
describe the static deployment view of a system. Deployment diagrams consist of nodes and
their relationships.

Figure 4.9: Deployment Diagram

Department of Computer Engineering 2019-20 22

Automatic Approach for E-Billing System for Online Application

Chapter 5

Project Plan

5.1 Project Estimates

5.1.1 Reconciled Estimates

Cost Estimate

Cost will estimate after completing the project that depend on time to complete the project.
Also efforts required to complete.

Time Estimates

Time will depend on modules of project.Also project plan of execution.

5.1.2 Project Resources

1. Hardware Resources Required

System: Pentium IV 2.4 GHz. Hard Disk: 40 GB. Floppy Drive: 44 Mb.
Monitor: 15 VGA Color.

2. Software Resources Required

Operating system: Windows. Coding Language: Java 1.8 Database: MySql 5
IDE: Eclipse

5.2 Risk Management

5.2.1 Risk Identification

For risks identification, review of scope document, requirements specifications and schedule is
done. Answers to questionnaire revealed some risks. Each risk is cate-

Department of Computer Engineering 2019-20 23

gorized as per the categories mentioned in [?]. Please refer table ?? for all the risks.
You can refereed following risk identification questionnaire.
1. Have top software and customer managers formally committed to support the
project?
Answer: Yes , Have top software and customer managers formally committed to support
the project
2. Are end-users enthusiastically committed to the project and the system/prod-uct to be
built?
Yse, end-users enthusiastically committed to the project and the system/prod-uct to be
built
3. Are requirements fully understood by the software engineering team and its
customers?
Yes, Are requirements fully understood by the software engineering team and its
customers
5. Have customers been involved fully in the definition of requirements? Yes,
customers been involved fully in the definition of requirements
6. Are project requirements stable? Answer: all
project requirements are stable
9. Is the number of people on the project team adequate to do the job? Yse, the
number of people on the project team adequate to do the job

5.2.2 Risk Analysis

Table 5.1: Risk Analysis

Following are the details for each risk.

Risk ID 1
Risk Description Description 1
1.While login to system validation is there so user must follow rules and propoer
enteries
Risk ID 2

Department of Computer Engineering 2019-20 24

1.While registering to system internet connection should be their for registration to get users
data online

5.3 Project Schedule

5.3.1 Project task set

Major Tasks in the Project stages are:

Task 1: Requirement Analysis (Base Paper Explanation).

Task 2: Project Specification (Paper Work).

Task 3: Technology Study and Design.

Task 4: Coding and Implementation (Module Development).

5.3.2 Task network

Figure 5.1: Task network

Department of Computer Engineering 2019-20 25

5.3.3 Timeline Chart

Figure 5.2: Timeline Chart

Department of Computer Engineering 2019-20 26

5.3.4 Timeline Chart

Figure 5.3: Timeline Chart

5.4 Team Organization

5.4.1 Team structure

Figure 5.4: Team structure

Department of Computer Engineering 2019-20 27

5.4.2 Management reporting and communication

Table 5.2: Management reporting and communication

Department of Computer Engineering 2019-20 28

Automatic Approach for E-Billing System for Online Application

Chapter 6

Project Implementation

6.1 Overview of Project Modules

1.User

Registration

Login

Search Product

Purchase Product

Generate Bills

Logout

2. Admin Module

Login

View Users

Authorize Users

Add Product

View Product

6.2 Tools and Technologies Used

6.2.1 Technology Description

In the Java programming language, all source code is first written in plain text files ending
with the .java extension. Those source files are then compiled into .class

Department of Computer Engineering 2019-20 29

files by the javac compiler. A .class file does not contain code that is native to your processor;
it instead contains bytecodes the machine language of the Java Virtual Machine1 (Java VM).
The java launcher tool then runs your application with an in-stance of the Java Virtual
Machine.

6.2.2 Hardware Specifications

Processor - I3,I5
Speed - 3.8 GHz
RAM - 4GB
Hard Disk - 1 TB
Key Board - Standard Windows Keyboard
Mouse - Two or Three Button Mouse
Monitor - LCD(Liquid Crystal Display)

6.2.3 Software Specifications

Operating System: Windows 10

Programming Language: JAVA
Backend: Mysql 5.0
IDE : Eclipse Oxygen
Tool:Apache Framework

6.3 Algorithm

6.3.1 AES Encryption Algorithm

AES (advanced encryption standard).It is symmetric algorithm. It used to convert plain text
into cipher text .The need for coming with this algo is weakness in DES. The 56 bit key of des
is no longer safe against attacks based on exhaustive key searches and 64-bit block also
consider asweak.AES was to be used128-bit block with128-bit keys.

Rijendeal was founder. In this drop we are using it to encrypt the data owner file.

Input:

Department of Computer Engineering 2019-20 30

128 bit /192 bit/256 bit input (0, 1)
Secret key (128 bit) +plain text (128 bit).
Process:
10/12/14-rounds for-128 bit /192 bit/256 bit input
Xor state block (i/p)
Final round:10,12,14
Each round consists: sub byte, shift byte, mix columns, add round key.
Output:
cipher text(128 bit)

Department of Computer Engineering 2019-20 31

Automatic Approach for E-Billing System for Online Application

Chapter 7

Software Testing

7.1 Types Of Testings

7.1.1 Unit testing

Unit testing involves the design of test cases that validate that the internal program logic is
functioning properly, and that program inputs produce valid outputs. All decision branches
and internal code flow should be validated. It is the testing of individual software units of the
application .it is done after the completion of an in-dividual unit before integration. This is a
structural testing, that relies on knowledge of its construction and is invasive. Unit tests
perform basic tests at component level and test a specific business process, application, and/or
system configuration. Unit tests ensure that each unique path of a business process performs
accurately to the documented specifications and contains clearly defined inputs and expected
results.

7.1.2 Integration testing

Integration tests are designed to test integrated software components to determine if they
actually run as one program. Testing is event driven and is more concerned with the basic
outcome of screens or fields. Integration tests demonstrate that al-though the components were
individually satisfaction, as shown by successfully unit testing, the combination of
components is correct and consistent. Integration testing is specifically aimed at exposing the
problems that arise from the combination of components.

Department of Computer Engineering 2019-20 32

7.1.3 Functional test

Functional tests provide systematic demonstrations that functions tested are avail-able as
specified by the business and technical requirements, system documentation, and user
manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be accepted.
Invalid Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised. Systems/Procedures:
interfacing systems or procedures must be invoked. Organization and preparation of functional
tests is focused on requirements, key functions, or special test cases. In addition, systematic
coverage pertaining to iden-tify Business process flows; data fields, predefined processes, and
successive pro-cesses must be considered for testing. Before functional testing is complete,
addi-tional tests are identified and the effective value of current tests is determined.

7.1.4 System Test

System testing ensures that the entire integrated software system meets require-ments. It tests
a configuration to ensure known and predictable results. An example of system testing is the
configuration oriented system integration test. System test-ing is based on process descriptions
and flows, emphasizing pre-driven process links and integration points.

7.1.5 White Box Testing

White Box Testing is a testing in which in which the software tester has knowledge of the
inner workings, structure and language of the software, or at least its purpose. It is purpose. It
is used to test areas that cannot be reached from a black box level.

7.1.6 Black Box Testing

Black Box Testing is testing the software without any knowledge of the inner work-ings,
structure or language of the module being tested. Black box tests, as most other kinds of tests,
must be written from a definitive source document, such as specifica-tion or requirements
document, such as specification or requirements document. It is a testing in which the software
under test is treated, as a black box .you cannot

Department of Computer Engineering 2019-20 33

“see” into it. The test provides inputs and responds to outputs without considering how the
software works.

7.1.7 Unit Testing:

Unit testing is usually conducted as part of a combined code and unit test phase of the
software lifecycle, although it is not uncommon for coding and unit testing to be conducted as
two distinct phases.

7.1.8 Integration Testing

Software integration testing is the incremental integration testing of two or more integrated
software components on a single platform to produce failures caused by interface defects. The
task of the integration test is to check that components or software applications, e.g.
components in a software system or – one step up – software applications at the company level
– interact without error.

7.1.9 Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires significant participation
by the end user. It also ensures that the system meets the functional requirements. Test
Results: All the test cases mentioned above passed successfully. No defects encountered.

7.2 Test cases and Test Results

Testing of project problem statement using generated test data (using mathematical models,
GUI, Function testing principles, if any) selection and appropriate use of testing tools, testing
of UML diagram’s reliability. Module-ID:-01
Modules to be tested:-Registration
1. Enter the case insensitive Username click on Submit button.
Expected: It should display error.
2. Enter the case sensitive Username click on Submit button.
Expected: It should accept.
3. Enter the case insensitive Password click on Submit button.
Expected: It should display error.
4. Enter the case sensitive Password click on Submit button.

Department of Computer Engineering 2019-20 34

Expected: It should accept.
5. Enter the case insensitive Mobile Number click on Submit button.
Expected: It should display error.
6. Enter the case sensitive Mobile Number click on Submit button.
Expected: It should accept.
7. Enter the wrong address and click on Submit button.
Expected: It should display error.
8. Enter the correct address and click on Submit button.
Expected: It should accept.

Department of Computer Engineering 2019-20 35

 Table 7.1: Test Cases

Module-ID:-2
Modules to be tested:- Login
1. Enter the correct username and wrong password click on Submit button.
Expected: It should display error.
2. Enter the wrong username and correct password and click on Submit button.
Expected: It should display error.
3. Enter the correct username and password and click on Login button.
Expected: It should display welcome page.
4. After login with valid credentials click on back button.

Department of Computer Engineering 2019-20 36

Expected: The page should be expired.
5. After login with valid credentials copy the URL and paste in another browser.
Expected: It should not display the user’s welcome page.
6. Check the password with Lower case and upper case.
Expected: Password should be case sensitive.

Table 7.2: Test Cases

Department of Computer Engineering 2019-20 37

Automatic Approach for E-Billing System for Online Application

Chapter 8

Results

8.1 Screen Shots

Figure 8.1: Home Page

Department of Computer Engineering 2019-20 38

 Figure 8.2: Admin Login Page

Department of Computer Engineering 2019-20 39

 Figure 8.3: Admin Home Page

Department of Computer Engineering 2019-20 40

 Figure 8.4: All Product Page

Department of Computer Engineering 2019-20 41

 Figure 8.5: View Product Review Page

Department of Computer Engineering 2019-20 42

 Figure 8.6: View individual product Page

Department of Computer Engineering 2019-20 43

 Figure 8.7: View review sentiment Page

Department of Computer Engineering 2019-20 44

 Figure 8.8: User Login Page

Department of Computer Engineering 2019-20 45

 Figure 8.9: Login Successfully Page

Department of Computer Engineering 2019-20 46

 Figure 8.10: User Home Page

Department of Computer Engineering 2019-20 47

 Figure 8.11: Search Product Page

Department of Computer Engineering 2019-20 48

 Figure 8.12: View all products Page

Department of Computer Engineering 2019-20 49

 Figure 8.13: Generate Bills Page

Department of Computer Engineering 2019-20 50

Automatic Approach for E-Billing System for Online Application

Chapter 9

CONCLUSION

9.1 Conclusion

This paper proposes an E-billing Framework towards data oriented taxation sys-tems.
Compared with current systems, the proposed data-oriented taxation system has the following
advantages:
Through automated generation and transmission of invoices. Tax
authorities could now directly acquire related transaction
details from e-invoices instead of communicate with taxpayers. The efficiency of taxation is
promoted and the cost is reduced.

Department of Computer Engineering 2019-20 51

Automatic Approach for E-Billing System for Online Application

References

[1] H. Richard, and I. Walden. ”The draft UNCITRAL model law for electronic commerce:
issues and solutions.” Computer Lawyer 13, 1996, pp.18-22.

[2] Y. Zeng, X. Guo, and H. Huang. ”E-commerce tax collection and administra-tion in
China.” Information Management, Innovation Management and Indus-trial Engineering
(ICIII), 2012 International Conference on. Vol. 3. IEEE, 2012, pp.424-427.

[3] S. Yang, and G. Liu. ”Research on E-commerce taxation from an angle of China.” E-
Business and E-Government (ICEE), 2011 International Conference on. IEEE, 2011,
pp.1-5.

[4] European Commission. ”European Electronic Invoicing (EEI) Final Report.” European
Commission Informal Task Force on e-Invoicing , 2007.

[5] C. Tanner, R. Wolfle,¨ P. Schubert, and M. Quade. ”Current trends and chal-lenges in
electronic procurement: an empirical study.”. Electronic Markets, 2008, pp.6-18.

[6] B. Koch. ”E-Invoicing/E-Billing in Europe. Taking the next step towards auto-mated
and optimised processes.” Billentis, Wil (2009).

[7] A. Kaliontzoglou, P. Boutsi, and D.Polemi. ”eInvoke: Secure eInvoicing based on web
services.” Electronic Commerce Research, 2006, 6(3-4), pp.337-353.

[8] D. Spanic, D. Ristic, and B Vrdoljak. ”An electronic invoicing system.”

Telecommunications (ConTEL), Proceedings of the 2011 11th International Conference
on. IEEE, 2011, pp.149-156.

[9] L. Humski, B. Vrdoljak, and Z. Skocir. ”Concept, development and implemen-tation of

FER e-invoice system.” Software, Telecommunications and Computer Networks
(SoftCOM), 2012 20th International Conference on. IEEE, 2012, pp.1-5.