MIS OF CNG STATION

Session (2017-2019)

Program
Master of Computer Science

Submitted By:
Saqib Ur Rehman 15-OG-87

Supervised By:
Dr. Hamad Sherazi
Assistant Professor, Department of IT

DEPARTMENT OF INFORMATION TECHNOLOGY

HAZARA UNIVERSITY MANSEHRA

 DECLARATION

This is to certify that to best of our knowledge the content of this thesis is our own
work except for quotations and citations that have been duly acknowledged. This
thesis has not been submitted for any degree or other purposes. We certify that the
intellectual content of this thesis is product of our own work and this thesis does not
infringe any copyright laws. All work here in this thesis is duly approved. If any part
of this software proved to be copied out from any source or found to be reproductive
of someone else, we shall standby the consequences. No portion of the work
presented in this report has been submitted in support any application from any other
degree of qualification of his or any other university or institute of learning. We
further declare that this software and all associated documents, reports and records
are submitted as partial requirement for the degree of MCS. We understand and
transfer copyrights for these materials to Hazara University.

Saqib Ur Rehman Signature: _______________

i
 ACKNOWLEDGMENT

With the great name of Allah, the most gracious and merciful, who gifted us
blessings, strength and mental powers, without which we could not complete this
project.

Thanks go to Dr. Arif Iqbal Umer (Head of Department) for providing us with great
inspiration, technical advice and lots of courage, feedback and patience.

Special thanks goes to our internal supervisor Mr. Hamad Sherazi whose support and
guidance played an important role in our achievements. His guidance and advice, both
mentally and technically has been of great importance to the final outcome of this
thesis. We are also thankful to all teachers and staff members here at IT Department
and our all class fellows. We are extremely thankful to our beloved Parents and
family whose prayers and continuous encouragement made the successful
completion of this project possible. Last but not least special thanks to all friends
who helped us for completion of this project.

ii
 TABLE OF CONTENT

CHAPTER 1 INTRODUCTION _____________________________________1

1.1 Introduction _____________________________________________________1
1.2 Introduction of Point of Sale ________________________________________1
1.3 Existing System __________________________________________________2
1.4 Advantages _____________________________________________________2
1.5 Streamline your manual record keeping _______________________________2
1.6 Drawbacks of the Existing System ___________________________________3
1.6.1 Slow in Processing: ___________________________________________3
1.6.2 Lack of Communication: _______________________________________3
1.6.3 Tedious Information Access: ____________________________________3
1.6.4 Chances of Inaccurate Calculations:_______________________________3
1.6.5 Excessive use of Stationary: _____________________________________4
1.6.6 Laziness of the System: ________________________________________4
1.6.7 Time Loss: __________________________________________________4
1.6.8 Manual Editing / Typing: _______________________________________4
1.6.9 Lack of Modern Software: ______________________________________4
1.6.10 Security: ___________________________________________________5
1.6.11 Report Generation: ___________________________________________5
1.6.12 Lack of Backup System: _______________________________________5
1.6.13 Inconsistency Problem:________________________________________5
1.6.14 Data Redundancy:____________________________________________5
1.7 Conclusion______________________________________________________6
CHAPTER 2 DEVELOPMENT METHODOLOGIES __________________1
2.1 Waterfall Model _______________________________________________7
2.1.1 Requirement Analysis: ________________________________________8
2.1.2 Design: ____________________________________________________8
2.1.3 Code Generation: ____________________________________________9
2.1.4 Testing: ____________________________________________________9
2.1.5 Maintenance: _______________________________________________9
2.2 Incremental Model _____________________________________________9
2.3 Agile Process Model __________________________________________10
2.4 Our choice of Methodology _____________________________________12

iii
 2.4.1 Requirement: ______________________________________________12
2.4.2 Architecture and Design: _____________________________________12
2.4.3 Development: ______________________________________________12
2.4.4 Test and Feedback: __________________________________________12
CHAPTER 3 REQUIREMENT ANALYSIS __________________________13
3.1 Introduction _________________________________________________13
3.1.1 Problem Recognition: ________________________________________13
3.1.2 Evaluation and synthesis: _____________________________________13
3.1.3 Modeling: _________________________________________________14
3.1.4 Requirement Specification: ___________________________________14
3.2 Requirement Analysis _________________________________________15
3.3 Normal Requirements _________________________________________15
3.3.1 Login System: ______________________________________________15
3.3.2 Report Generation: __________________________________________15
3.4.1 Easy Human Computer Interface: ______________________________16
3.4.2 Consistency: _______________________________________________16
3.4.3 Reliability: ________________________________________________16
3.4.4 Overall Operational Correctness: _______________________________16
3.4.5 Minimum number of Clicks required: ___________________________16
3.3.6 Usability Requirements: ______________________________________17
3.4.7 Security Requirements:_______________________________________17
3.4.8 Performance Requirements: ___________________________________17
CHAPTER 4 PROPOSED SYSTEM ________________________________12
4.1 Need of Proposed System ______________________________________18
4.2 Advantages of System _________________________________________18
4.3 Objectives ___________________________________________________18
4.4 Features of the Proposed System __________________________________18
4.4.1 Security: __________________________________________________18
4.4.2 User Friendly: ______________________________________________19
4.4.3 Less Time-Consuming:_______________________________________19
4.4.4 Error Free:_________________________________________________19
4.4.5 Generation of Reports: _______________________________________19
4.5 Modules ____________________________________________________19
4.5.1 General User Interface: _______________________________________19

iv
 4.5.2 Login Module: _____________________________________________19
4.6 Module of project: ____________________________________________20
4.7 Block Diagram _______________________________________________21
CHAPTER 5 REQUIREMENT MODELING _________________________16
5.1 Introduction _________________________________________________22
5.1.1 Requirement Modeling: ______________________________________22
5.1.2 Explanation: _______________________________________________22
5.1.3 Objectives: ________________________________________________23
5.2 Data Modeling _______________________________________________23
5.2.1 Entity: ____________________________________________________24
5.2.2 Weak Entity: _______________________________________________24
5.2.3 Strong Entity: ______________________________________________24
5.2.4 Entity Set: _________________________________________________24
5.2.5 Attribute: __________________________________________________24
5.2.6 Key: _____________________________________________________24
5.2.7 Relations: _________________________________________________25
5.3 Symbols used in ER Diagrams _____________________________________25
5.4 Major Entities Used in This Project _________________________________25
5.5 Entity Relationship Diagram of This Project: __________________________27
5.6 Functional Modeling __________________________________________28
5.6.1 Symbols Used In DFD:_______________________________________28
5.6.2 Data Flow Diagrams of This Project: ____________________________29
5.6.2.1 Context Level DFD _______________________________________29
5.6.2.2 First Level DFD: ___________________________________________30
5.6.2.3 Second Level DFD: _________________________________________31
CHAPTER 6 DATABASE DESIGN PROCESS _______________________20
6.1 Database Design Process _______________________________________32
6.2 Necessary Conditions for a Good Database Design___________________32
6.3 Four Steps in Database Design Process ____________________________32
6.3.1 Requirement Analysis: _______________________________________32
6.3.2 Conceptual Design:__________________________________________33
6.3.2.1Entity Relationship Diagram (ERD): ____________________________33
6.3.3 Logical Design:_____________________________________________33
6.3.3.1 Normalization: ____________________________________________33

v
 6.3.3.1.1 Un-normalized Table (PRODUCT) _________________________34
6.3.3.1.2 1st Normal Form: ________________________________________34
6.3.3.1.3 2nd Normal Form: _______________________________________35
6.3.3.2 Data Dictionary of the Project _____________________________ 36
6.3.4 Physical design: ____________________________________________38
6.4 The Database Diagram of the System _____________________________39
CHAPTER 7 FRAMEWORK ______________________________________29
7.1 Framework __________________________________________________40
7.2 Visual Languages _____________________________________________41
7.3 Visual C# ___________________________________________________41
7.4 Advantages __________________________________________________41
CHAPTER 8 DATABASE MANAGEMENT SYSTEM _________________35
8.1 Relational database management systems (RDBMS) _________________43
8.2 SQL Server __________________________________________________44
8.3 SQL Server Management Studio____________________________________44
CHAPTER 9 IMPEMENTATION AND TESTING ____________________38
9.1 Implementation and Testing _____________________________________45
9.2 User Interface Implementation ___________________________________45
9.3 Implementation of Functional Requirements ________________________45
9.4 Implementation of System requirements ___________________________45
9.4.1 Authentication and Authorization: ______________________________45
9.5 Testing _____________________________________________________46
9.5.1 White Box Testing: __________________________________________46
9.5.2 Black Box Testing: __________________________________________47
CHAPTER 10 USER INTERFACE __________________________________40
10.2 Admin Login ________________________________________________49
10.3 Main Form __________________________________________________50
10.4 View Category _______________________________________________50
10.5 Add Category _________________________________________________51
10.6 Stock Record ________________________________________________51
10.7 Add Stock ___________________________________________________52
REFERENCES ____________________________________________________53

vi
 LIST OF FIGURES

Figure 2.1: Water Fall Model......................................................................................... 8

Figure 4.1: Block Diagram for Main Module .............................................................. 21

Figure 5.1: Entity Relationship Diagram Symbols. ..................................................... 25

Figure 5.2: ERD of the System ................................................................................... 27

Figure 5.3: Data Flow Diagram Symbols. .................................................................. 28

Figure 5.4: Context Level DFD. ................................................................................. 29

Figure 5.5: First Level DFD........................................................................................ 30

Figure 5.6: Level 2 DFD. ............................................................................................ 31

Figure 10.1: Splash Screen ......................................................................................... 49

Figure 10.2: Snapshot of Admin Login Form. ............................................................ 49

Figure 10.3: Main Form .............................................................................................. 50

Figure 10.4: View Category........................................................................................ 50

Figure 10.5: Add Category ......................................................................................... 51

Figure 10.6: Stock Record. ......................................................................................... 51

Figure 10.7: Add Stock ............................................................................................... 52

vii
 LIST OF TABLES

Table 6.1: Un-normalized table of products with repeating values. ........................... 34

Table 6.2: 1st Normal Form, table product. ................................................................. 34

Table 6.3 1st Normal Form, table category. ................................................................. 35

Table 6.4: 2nd Normal Form, table product. ................................................................ 35

Table 6.5: data dictionary of table product. ................................................................. 36

viii
 LIST OF ABBREVIATION

ERD Entity Relationship Diagram

DFD Data flow Diagram

DB Data Base

DBMS Data Base Management System

GUI Graphical User Interface

MIS Management Information System

Fig Figure

IT Information Technology

ix
 CHAPTER 1
INTRODUCTION
1.1 Introduction

This is a general software which is developed for CNG Station. During a survey of an
CNG Station I noted their “record keeping” which was a difficult one and manual as
well. The record was kept in the form of writing in a note book. Storing data in this
form is not only difficult but it also create problem while searching for it after a year
or two. The plant need to be managed according to the current digital technology. It
will help the company to get the required information from their data by just applying
a single query and they will make their future planning regarding the buying selling
according to this information that they have. The software will not only save time but
it will also help to reduce labor. It will also save a lot of paper from exploitation. The
management will also be able to have a backup of their data. It will be so easy to add
new thing to the data base according to the organization needs in future.
1.2 Introduction of Point of Sale
The point of sale (POS) or point of purchase (POP) is the time and place where a
retail transaction is completed. At the point of sale, the merchant would calculate the
amount owed by the customer and indicate the amount and may prepare an invoice for
the customer (which may be a cash register printout), and indicate the options for the
customer to make payment. It is also the point at which a customer makes a payment
to the merchant in exchange for goods or after provision of a service. After receiving
payment, the merchant may issue a receipt for the transaction, which is usually
printed, but is increasingly being dispensed with or sent electronically.
To calculate the amount owed by a customer, the merchant may use any of a variety
of aids available, such as weighing scales, bar code scanners, electronic and manual
cash registers. To make a payment, EFTPOS terminals, touch screens and a variety of
other hardware and software options are available.
The point of sale is often referred to as the point of service because it is not just a
point of sale but also a point of return or customer order. Additionally, current POS
terminal software may include additional features to cater for different functionality,
such as inventory management, CRM, financials, or warehousing.
Businesses are increasingly adopting POS systems and one of the most obvious and
compelling reasons is that a POS system does away with the need for price tags.
Selling prices are linked to the product code of an item when adding stock, so the
cashier merely needs to scan this code to process a sale. If there is a price change, this

1
can also be easily done through the inventory window. Other advantages include
ability to implement various types of discounts, a loyalty scheme for customers and
more efficient stock control.
1.3 Existing System
CNG management system is running manually by entering all data in registers. Some
business owners may want to use a simple, paper-based record keeping system. The
main areas in this domain which is of importance to the plant are given bellow.

1.4 Advantages

 Less expensive to set up.

 Correcting entries may be easier with manual systems, as opposed to

computerized ones that can leave complicated audit trails.

 The risk of corrupted data is much less.

 Data loss is less of a risk, particularly if records are stored in a fire-proof

environment.

 Problems with duplicate copies of the same records are generally avoided.

 The process is simplified as you don't need to be familiar with how accounting
software calculates and treats your information.

1.5 Streamline your manual record keeping

 Sort and store all paperwork, receipts and payments in 12 separate months.

 Keep all original documents and date all correspondence.

 Record all transaction dates and payment amounts.

 User can save all sale/purchase record by month and financial year in software
which has capability of backup.

 Capture nearly all of your income and expenses in statements from both your
bank and credit card accounts.

2
  Request that all statements and bills be sent on a monthly basis - allowing you
to reconcile all financial records each month.
1.6 Drawbacks of the Existing System

Existing management of CNG is done through manual entries in registers which may
takes very much time. Moreover manual calculation of CNG purchase and sale may
create error. Traditional system contains many loopholes and information in such a
system is at constant risk of flood, fire, theft, and simply paper being misfiled. This
system is not user friendly because administrator needs to spend a lot of time finding
specific data. Manual system is beneficial to the Office or to the individual, if their
requirements are simple and amount of data to be processed is limited but when data
volume is increased, and then it is difficult to manage data.
1.6.1 Slow in Processing:

It is difficult to access and retrieve the records quickly because the data is scattered in
different files and to search out the specific information or record from these files is a
complicated process and the basic milestone for delayed information in the laziness of
the system, that delay in information causes time wastage and sometime great loss.
1.6.2 Lack of Communication:

Lack of communication between seller and buyer is major drawback of the existing
system. Usually, customers have to visit the workshop to get information about their
services and deals. Sometimes, in their busy routine it is not possible for them to visit
workshop regularly. MIS System will allow them to check their required services.
1.6.3 Tedious Information Access:

In the existing form of system, it is very difficult to access information quickly. If we

want to retrieve any record of, say, a product, it is tedious and difficult.
1.6.4 Chances of Inaccurate Calculations:

As the records are maintained manually, so there is a big chance of inaccurate

calculations and can result in a loss. Like calculating the sales of a specific time / date
/ or month is difficult and there is a maximum chance of inaccurate calculations as per
human mistakes.

3
1.6.5 Excessive use of Stationary:

During the manipulation of records, the maintenance of record consumes a lot of

stationary for the storage, retrieval, printing and processing purpose.

1.6.6 Laziness of the System:

As the current system is manual, all the data that is stored in different
scattered paper files so accessing and retrieving particular record or
information is very difficult and time consuming process. Sometime,
administration requires specific information quickly to make some quick
decisions but it becomes difficult and sometimes impossible because of the
laziness of the manual system.

1.6.7 Time Loss:

The most important factor for measuring the efficiency of any system is time. The
hectic searching for finding the records are the basic reason for the wastage of time
because all the records are stored in different files and searching from them is an
ambiguous process. Saving of records consumes many working hours and costs
heavily. So manual system also takes much time to maintain, select and prepare the
record file, which badly effects efficiency of the system.

1.6.8 Manual Editing / Typing:

The editing procedure in the manual system is done using pen, paper and cash memos
which look awkward and it is also difficult to make certain changes in it.

1.6.9 Lack of Modern Software:

Computer professionals cannot work in a smooth way, as no specific program is

present to fulfill the all objectives. No proper system of input formats for updating.
Conventional files system is being used for maintenance of data files, but without any
standardized modules for input/output.

4
1.6.10 Security:

Data is very important and sensitive assets for the institution therefore, it is very
necessary to protect or secure that data. Data and information of existing system is not
safe. A number of persons who involved in this process and there is a chance that data
can be destroyed or misplaced by unauthorized person in the absence of concerned
person.

1.6.11 Report Generation:

Difference kinds of reports like stock report, monthly sales reports etc. are very
important for plant. These reports are most frequently used. These reports are quite
difficult to generate manually. Sometimes these reports are required to be converted
into different formats like pdf or MS Word.

1.6.12 Lack of Backup System:

Lack of backup system is another problem with existing system. If important

information gets lost accidently, then current system does not provide any mechanism
to get that data back. Data is very important asset for any organization, if backup
system is not maintained to protect the data then any accident or damage to the
equipment may deprive the organization from its precious asset.

1.6.13 Inconsistency Problem:

As the records are maintained in different levels/registers, therefore a small change in

the record at one level can lead to inconsistency because there is no way to update the
specific record to maintain in other level/register.

1.6.14 Data Redundancy:

While analyzing the current system, it has been found that the current system has as
excessive amount of data redundancy. It is exhibited by the common set of records
across several manually kept documents. The records are maintained at several places
and it causes redundancy of data that are stored at more than one place which not only
wastes the man hours but also the stationary.

5
1.7 Conclusion

Above drawbacks of existing system shows the inefficiency of existing system, so a

new management system is required in order to solve these problems. This application
will remove all these deficiencies of current system and will enhance efficiency of the
institute.

6
 CHAPTER 2

DEVELOPMENT METHODOLOGIES
In this chapter we will discuss different system development methodologies which are
usually followed by software or web app developers. We will choose one suitable
methodology from them for our project along with reason to choose it at the end of
this chapter.

Software developers in the software engineering world use a methodology to control

the process, monitor the progress, and gather information and resources accurately. In
the terms of software development, this methodology is called a framework or process
model. There are several types of frameworks (methodologies), such as the Waterfall
model, Incremental model; Prototype model, Spiral model, iterative and Rapid
Application Development model.

Actually, a software process model or software development methodology is a series

of predictable steps or road map that help us to create a timely, high-quality software
or Web App. A process model may include activities that are part of the software
process which consists of all possible actions for developing software from initial
stage to final stage. There are different types of software development methodologies
or process models. A suitable process model is chosen by the software engineer or
web developer based on the nature of project and application, the methods and tools
to be used.

In following section some models will be discussed:

2.1 Waterfall Model

The Waterfall model was suggested by W. Royce, and can be called a classic life
cycle or linear sequential model. This model comprises five separated phases that are
connected together sequentially. Starting each phase during the process depends on
the finalization of the current phase under processing. For example, the design phase
cannot be started unless the requirement phase has been finalized. As with other
models, the Waterfall model has advantages. The main advantage is that it is easy to
understand because it is sequentially organized. However, there are disadvantages,
such as clients cannot see the system unless it goes through all the model phases.
Another disadvantage is that developers cannot be sure whether the requirements are
realized. Figure shows the Waterfall model.

7
 Figure 2.1: Water Fall Model.

2.1.1 Requirement Analysis:

In order to understand the nature of programs to be built, the system analyst must
understand the information domain of the system as well as the function, behavior,
performance and interface. At this stage requirements for both the system and
software are documented and discussed with customer. In this stage analyst discuss
the nature of the software, behavior and performance of the software as well as the
environment of the system with the customers.

2.1.2 Design:

Design is a meaningful representation of anything that is to be built. Design is the first

technical representation of the system. Design translates requirements into a
representation of the software that can be accessed for quality. Design is also
documented like requirements. Design can be performed before coding steps.

Some steps in design are:

 Data design

8
  Architecture design.
 Interface design
 Compound level design.

2.1.3 Code Generation:

The code generation performs the task of design translation into a machine readable
form. For this any computer language can be used. If design is done in a good
manner, then code generation is easy.

2.1.4 Testing:

After code generation testing begins. The testing may be white box and black box
testing. In white box testing logical internals of the software is tested while in black
box testing functional external are tested to uncover as many errors as possible.

2.1.5 Maintenance:

In order to accommodate with new changes in the environment, system should be

updated with passage of time. The system must support adaptation (adding new
peripherals, o/s etc.) enhancements (improve the software) and also prevention
(prevention from illegal changes).
2.2 Incremental Model

In the Incremental model process same phases as the Waterfall model process are
used, but the steps in the Incremental model need a fewer time to complete in
comparison to the steps in the Waterfall model. This is because at the beginning of the
process in the Incremental model, a new version of the product will be released with
basic requirements; this version is called the core product. After gathering new
requirements, a new version will be available, which is called the new increment.
Each increment comprises much new functionality. This model has advantages, such
as the fact that at the beginning of the process a small number of development staff
can be involved. Moreover, the core product can be seen by the client before finishing
other versions. Furthermore, what the earlier increment lacks will be fixed in the
future increment. However, this model has disadvantages, such as the fact that an

9
earlier iteration will be cancelled by the introduction of the new iteration, which might
be not functional. Moreover, new technologies may be needed in future increments.

Figure shows the Incremental model.

Figure 2.2: Incremental Model.

2.3 Agile Process Model

So-called lightweight Agile Software Development Method evolved in the mid-

1990s while Agile Manifesto was published in 2001. The Agile Model is an
evolutionary software development process model which is combination of iterative
and incremental techniques with the controlled and systematic aspects of the linear
sequential model. It provides the potential for component based development of
project and produces a deliverable product after single iteration. The basic purpose of
using agile method is that iteration moves on a single component and after iteration a
complete tested and deliverable module is produced, at the end all the components are
integrated and whole project is completed in a reasonable time period.

10
Unlike the waterfall model in agile model very limited planning is required to get
started with the project. Agile assumes that the end users’ needs are ever changing in
a dynamic business and IT world. Changes can be discussed and features can be
newly effected or removed based on feedback.

The task regions of Agile Method are as follow:

 Planning.
 Requirement Analysis.
 Designing.
 Building.
 Testing.

Figure 2.3: Agile Process Model.

11
2.4 Our choice of Methodology

Process model is a roadmap for developing any computer based system in a proper
way. The project development needs to follow such process model which completely
meets the requirement of project. All the discussed methodologies have strengths and
weaknesses, but for this project because the requirements were not sufficient at the
first step of the design and coding stage, the agile model has been chosen, as in our
project there are incrementing as well as iterative approaches required for
development so the best process model selection for the best development was an
important task. We choose one of the latest and advance process model named “Agile
Process Model” for our project which completely meets our requirement.

The context level block diagram explains the iteration on a single component with
backtracking facility.

2.4.1 Requirement:

In this phase the basic requirements about Diagnostic Devices was gathered i-e how
records are maintained? How customers place order for their desired device? How
products will be delivered to customers? What will be transaction mechanism? etc.

2.4.2 Architecture and Design:

After basic requirement gathering the architecture of component is designed and if

needed further requirement we again go through requirement phase. The complete
architecture of a single component was designed in this phase.

2.4.3 Development:

In next phase the development process is started according to design and requirement,
if development phase need any change in design then we can go through design phase
again .in development coding is done for required functionality of component.

2.4.4 Test and Feedback:

In this phase the development of the component is tested that weather it meets our
requirement or not. The feedback from customer can also be done in this phase.

12
 CHAPTER 3

REQUIREMENT ANALYSIS
3.1 Introduction

Requirement analysis is the first technical step in the software engineering process.
Requirement analysis involves understanding the problem, establishing functions that
the system should perform, and the constraints under which the system must operate.
Requirement analysis provides foundation for all software engineering activities that
follow. One can’t build any good system without doing proper analysis. The
robustness and reliability of the software depend on it. The main objective of this
phase is to identify the problem and then solution is proposed.

Requirement analysis activities result in the specification of software’s operational

characteristics (function, data, and behavior), indicate software’s interface with other
system elements, and establish constraints that software must meet. Requirements
Analysis may be divided into following areas of effort:

3.1.1 Problem Recognition:

The goal of this phase is recognition of the basic problem elements as perceived by
the customer/user. In this phase requirements are elicited from customer/user by using
different requirements elicitation techniques like meeting or interview.

Detailed list of requirements is established after meeting with customer and analyzing
drawbacks of existing systems. All functional and non-functional requirements are
briefly analyzed to find out proper solution of the problem. If we don’t recognize
accurate problem to be solved, then it is possible that we will build a very elegant
software solution that solves the wrong problem. This chapter is fully devoted to
problem recognition phase.

3.1.2 Evaluation and synthesis:

Problem evaluation and solution synthesis is the next major area of effort for analysis.
The analyst must define all externally observable data objects, evaluate the flow and
content of information, define and elaborate all software functions, understand
software behavior in the context of events that affect the system, establish system
interface characteristics, and uncover additional design constraints. Each of these
tasks serves to describe the problem so that an overall approach or solution may be

13
synthesized. Upcoming chapters, after this one, are fully devoted to problem
evaluation and solution synthesis phase in which we will discuss the functions and
behaviors of the proposed systems and will also discuss scope of the system.

3.1.3 Modeling:

Models are created to gain a better understanding of the actual entity to be built.
Models created during requirements analysis serve a number of important roles. The
model aids the analyst in understanding the information, function, and behavior of a
system, thereby making the requirements analysis task easier and more systematic.
We will briefly discuss the modeling and will construct different models (like DFD,
ERD, and Use Cases) in relevant chapter.

3.1.4 Requirement Specification:

Requirement Specification is produced at the end of the analysis task. The function
and performance of the software as discussed in ‘Proposed System’ are refined by
establishing a complete information description, a detailed function description, a
representation of system behavior, an indication of performance requirements and
design constraints, appropriate validation criteria, and other information related to
requirements.
 The introduction of the software requirement specification states the goals
and objectives of the system, describing it in the context of the computer-
based system.
 The Information Description provides a detailed description of the problem
that the system must solve. Information content, flow, and structure are
documented. Hardware, software, and human interfaces are described for
external system elements and internal software functions.
 A description of each function required to solve the problem is presented in
the Functional Description. A processing narrative is provided for each
function, design constraints are stated and justified, performance
characteristics are stated, and one or more diagrams are included to
graphically represent the overall structure of the system.

14
  The Behavioral Description section of the specification examines the
operation of the system as a consequence of external events and internally
generated control characteristics.
3.2 Requirement Analysis

In this section we will discuss detail of requirements for developing Accounts and
Inventory Management System. Some requirements are elicited form workshop
administration and some are established during analyzing drawbacks of existing
system. Requirements are categorized into normal and expected requirements.
3.3 Normal Requirements

Normal requirements are those necessary requirements which are proposed or

suggested by the customer. These requirements are objectives and goals that are stated
for a product or system during meetings with the customer. If these requirements are
present, the customer is satisfied. Normal requirements of this system are discussed
below:

3.3.1 Login System:

Second requirement of the system is that the system should provide such a mechanism
which restricts access to confidential records. The Login system is required to allow
all stakeholders to get access only to their relevant area. For example, user could not
post any advertisement without login, or only concerned person / stakeholder can
access the admin panel and back-end of the system. Like adding, updating, deleting of
products / accounts can only be done by logged admin.

3.3.2 Report Generation:

Another important required feature of the system is to create different kinds of

reports. Reports are very important in a shop environment. For example, list report of
students in different courses. Sales report for the specific date / week / month etc. In
future system should be able to convert these reports in most frequently used formats
like pdf or MS Word etc.

15
3.4 Expected Requirements

These requirements are implicit to the system and may be so fundamental that the
customer does not explicitly state them. Their absence will be a cause for significant
dissatisfaction. Examples of expected requirements are: ease of human/machine
interaction, overall operational correctness and reliability. Following are some
expected requirements for this system.

3.4.1 Easy Human Computer Interface:

In every software or system human computer interface is the most important because
users are not concerned how the things work; they are more concerned about their
ease, so the interface has to be made according to user requirements. What do they
like and what is convenient for them.

3.4.2 Consistency:

All forms should have a consistent format for menu selection, data display and
command input. All the titles are same color and font. So that user’s needs not to learn
every screen.

3.4.3 Reliability:

Each module of the system should be reliable.

3.4.4 Overall Operational Correctness:

Each module should work accurately and according to the expectations of the user.

3.4.5 Minimum number of Clicks required:

Minimum number of clicks is required to get the output. This concept is used in whole
application. The user have just to enter the records, which are necessary, there is no
need to fill out redundant information.

16
3.3.6 Usability Requirements:

Usability is an attempt to quantify user friendliness. System is easy to learn and

operate. For this, the users don’t have to wade through extraneous buttons/links.
Every easy navigation approach is adopted.

3.4.7 Security Requirements:

Data provided by the user will be verified by the system very carefully so that security
of the system could be maintained. All the possible steps should be taken in order to
ensure security and reliability.

3.4.8 Performance Requirements:

Performance consideration encompasses processing speed, and response time. In

order to do this all possible steps should be taken for example graphics should be
optimized so that they can be loaded quickly.

17
 CHAPTER 4
PROPOSED SYSTEM
The proposed system is being developed for CNG Station dealer to manage their
records such as purchase record, sales record, customers record, stock record etc. The
goals of a system are to implement the organizational structure and dynamics of the
enterprise for the purpose of managing the organization in a better way and capturing
the potential of the information system for competitive advantage. It will help the
company to get the required information from their data by just applying a single
query and they will make their future planning regarding the buying selling according
to this information that they have.
4.1 Need of Proposed System

Record management is very difficult and time consuming in the existing manual
system. Existing system takes a lot of time in calculating the sales and purchase
records. Therefore to overcome these problems a computerized system is needed.
4.2 Advantages of System

 Reduce business costs - less time spent talking to customers over the phone:
eliminate printed materials.
 Centralized data is secure and easy to backup.
 Quick and easy updates.
 Low specification PCs or smart phones can be used.
4.3 Objectives

The main objective of system is to provide an efficient, interactive and collaborative

environment for the people to compare what they are looking for to what they want.
4.4 Features of the Proposed System

The proposed systems have lot of advantages some of them are given below.

4.4.1 Security:

The proposed system is secure and reliable. Different levels are developed for end
user and they can only access or edit data according to their privileges. So no
unauthorized person can access the information that he is not supposed to access.

18
4.4.2 User Friendly:

Proposed system is very user-friendly as the data inputs (through forms) and
generation of reports is very easy which the administration and users of the system
frequently require.

4.4.3 Less Time-Consuming:

It is less time-consuming, as software itself performs all the tasks. All the data of
products, sales, inventory, supplier, customer, accounts etc. is available which is
accessed faster as compared to manual system.

4.4.4 Error Free:

The proposed system is less error prone. Human mistakes occurred during day to day
jobs are minimized due to minimum data entry.

4.4.5 Generation of Reports:

This system provides facility to generate reports of sales per month, week or date.
Customers records, orders, etc
4.5 Modules

The application has different modules for different users of the system. Each module
has different functionalities and accessibility levels. In the following each module is
discussed in detail.

4.5.1 General User Interface:

This is the portion of System which will be accessible to users. This part of site is for
general users therefore they need to be authenticated or authorized by the system. In
this section different kind of information is provided like Customers, Supplier,
Accounts, Sales and Purchase etc.

4.5.2 Login Module:

Login module is used to check whether the user is an authorized person to use the
system or not. This module will be available on home page of the site. When user will

19
click on the login button a form will appear which will demand email address and
password. For this the user should give the correct email address and password. The
system will verify ID and password to determine whether the user is authorized or
not.

4.5.3 Admin Panel:

Admin Login and control panel is connected to the front end of the website. Only the
administration of the shop is concerned with admin panel. Adding, updating, deleting
of new products and accounts is done by admin
4.6 Module of project:

The proposed system will provide facilities such as

 Product Information
 Product Category
 Customer Information
 Supplier Information
 Purchase Information
 Purchase Detail
 Sales Information

 Sales Detail

20
4.7 Block Diagram

User/Admin

Login

Product
Reports

Customer

Supplier

Data Base
Purchase

Sales

Stock

Figure 4.1: Block Diagram for Main Module

21
 CHAPTER 5

REQUIREMENT MODELING
5.1 Introduction

Requirement modeling phase comes after Requirement Analysis. Requirements

Analysis results in the specification of system’s operational characteristics, indicates
system’s interface with other system elements, and establishes constraints that system
must meet. In fact Requirement analysis determines requirements for proposed system
and Requirement Modeling represents these requirements into a convenient
diagrammatic and textual form.

5.1.1 Requirement Modeling:

Requirement modeling or Analysis modeling uses a combination of text and

diagrammatic form to map or represent the requirement for data, function and the
behavior in a way that is easy to understand and straightforward to review for the
correctness, completeness and consistency.

The requirement modeling action results in one or more of the following types of
models:
 Scenario-based models or requirements from the point of view of various
actors of the system.
 Data models that depict the information domain for the problem.
 Flow-oriented models that represent the function elements of the system
and how they transform data as it move through the system.
 Behavioral models that depict how the system behaves as a consequence
of external “events”.

These models provide a software designer or web-application designer with

information that can be translated to architectural, interface, and component-level
designs. Finally the requirements model and system requirement specification
provides the developer and the customer with the means to assess quality once system
is built

5.1.2 Explanation:

At a technical level software engineering begins with a series of modeling activities

that leads to

22
  Complete specification of requirements.
 Design representation of the software that is to be built.

So for this the requirement modeling which is a set of models and is the first technical
representation of a system.

5.1.3 Objectives:

There are three main objectives of analysis or requirement modeling:

 To describe what the customer requires.
 To establish a bases for system design and
 To define a set of requirements that can be validated once the software is
built.

Models are created to gain a better understanding of the actual entity to be built.
Models created during requirements analysis serve a number of important roles. The
model aids the analyst in understanding the information, function, and behavior of a
system, thereby making the requirements analysis task easier and more systematic.
We will briefly discuss the modeling and will construct different models (like DFD
and ERD) in this chapter.
5.2 Data Modeling

Data modeling is the first modeling activity. To model or represent data of the system
is called data modeling. Data modeling is the activity of defining all the data objects
that consist of large collection of information transform by the system. For example
data object PRODUCT is an important piece of data.

For data modeling Entity Relationship Diagram abbreviated as ERD is used. The
entity relationship diagram of the proposed system is the detailed logical
representation of the data entities and relationships.

ERD is represented in the form of entities, the relationships among them and the
attributes of the entities i.e. the major construct of the (E_R) models are entities,
relationships and attributes. Each entity is constructed independently and relational
symbols are used to describe the relationship among them.

23
We can easily translate ER models into relational schemas. Data modeling/conceptual
modeling answers a set of specific questions that are relevant to any data processing
application.
 What are primary data objects to be processed?
 What is the composition of each object?
 What attributes describe each object?
 What are relationships between objects?
 What are relationship between the objects and relationships that
transform them?

5.2.1 Entity:

Anything about which we can collect information is called Entity. An entity is a real
world object. Entities are classified as follows:

5.2.2 Weak Entity:

Entities that’s existence depends on other entities (e.g. parent/child)

5.2.3 Strong Entity:

Entity that does not depends on other entities for their existence.

5.2.4 Entity Set:

An entity set is collection of similar entities e.g. all students. All entities in the set
have same set of properties. Each entity set has a key.

5.2.5 Attribute:

An attribute is a property or characteristics of an entity that is of interest.

5.2.6 Key:

Key is an attribute of an entity which uniquely identifies an instance of the entity set.

24
5.2.7 Relations:

A relationship is an association between two or more entities. There are three kinds of
binary relationships:
 One-to-One
 One-to-many
 Many-to-many

5.3 Symbols used in ER Diagrams

The following are common symbols, which are used in Entity Relationship Diagrams:

It is used for Entity.

It is used for attribute.

It is used for representing Relation

between entities.

It represents one-to-many relationships.

It represents many-to-many relationships.

Figure 5.1: Entity Relationship Diagram Symbols.

5.4 Major Entities Used in This Project

The following are some major entities of our project.

25
Attributes with defines primary key and attributes with defines foreign
key.
 Products
(product_id, product_name, weight, image, category_id, price, description).
 Product_Category
(category_id,category_name).
 Product_order
(order_id, product_id, order_note, email, contact, address, order_quantity,
total_cost, order_date, order_status).
 Customer
(customer_id, name, address, contact_no).
 Supplier
(supplier_id, title, address, contact_no).

26
5.5 Entity Relationship Diagram of This Project:

SUPPLIER

Process

PURCHASE ORDER

Order
CUSTOMER

Place

include SALE ORDER

PRODUCT

Has CATEGORY

Figure 5.2: ERD of the System

27
5.6 Functional Modeling

Functional modeling is also an important activity in analysis modeling. This shows

that how the data flow inside the system and what transformation occur to data as
the data flow. Functional modeling is discussed in terms of information flow;
information is transformed as it flows through system.

Information is transformed as it flows inside a computer based system. In functional

modeling we show that:
 How the data is processing?
 What are the input and output?
 Who input data and receive output?

We have used the data flow model to decompose the subsystems into different
modules. Each subsystem is decomposed into functional modules, which accept input
data transform it, in some way, to output data.

5.6.1 Symbols Used In DFD:

The dataflow model shows how different systems and subsystems exchange
information. The following symbols are used in DFD:

Shows source or Sink.

Shows Process

Show Flow of Data.

Show Data Source.

Figure 5.3: Data Flow Diagram Symbols.

28
5.6.2 Data Flow Diagrams of This Project:
A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modeling its process aspects. A DFD is often used as a
preliminary step to create an overview of the system, which can later be elaborated.
DFDs can also be used for the visualization of data processing (structured design).
A DFD shows what kind of information will be input to and output from the system,
where the data will come from and go to, and where the data will be stored. It does
not show information about the timing of process or information about whether
processes will operate in sequence or in parallel (which is shown on a flowchart).

5.6.2.1 Context Level DFD:

A context level DFD is the most basic form of DFD. It aims to show how the entire
system works at a glance. There is only one process in the system and all the data
flows either into or out of this process. Context level DFD’s demonstrates the
interactions between the process and external entities. They do not contain Data
Stores.
When drawing Context Level DFD’s, we must first identify the process, all the
external entities and all the data flows. We must also state any assumptions we make
about the system. It is advised that we draw the process in the middle of the page. We
then draw our external entities in the corners and finally connect our entities to our
process with the data flows.

Figure 5.4: Context Level DFD.

29
5.6.2.2 First Level DFD:
Level 1 DFD’s aim to give an overview of the full system. They look at the system in
more detail. Major processes are broken down into sub-processes. Level 1 DFD’s also
indentifies data stores that are used by the major processes.
When constructing a Level 1 DFD, we must start by examining the Context Level
DFD. We must break up the single process into its sub-processes. We must then pick
out the data stores from the text we are given and include them in our DFD. Like the
Context Level DFD’s, all entities, data stores and processes must be labeled. We must
also state any assumptions made from the text.

Figure 5.5: First Level DFD.

30
5.6.2.3 Second Level DFD:

Second Level or Level 2 DFD briefly explains the flow of data in our project. Here
admin manages the whole system after login and add / update / delete all the records
in database and also accept / reject orders. Figure completely explains the overall
flow.

Figure 5.6: Level 2 DFD.

31
 CHAPTER 6

DATABASE DESIGN PROCESS

6.1 Database Design Process

Database design is a very important part of developing the system. This part of the
system is the first step to take after gathering and organizing the requirements. This
step is taken in order to represent data that is used in the system with its relationships
in an appropriate way. This crucial part must be treated very carefully and accurately
because any lack or weaknesses in the process of designing the database leads to
inconsistency and redundancy in the data through the system, as well suffering in
terms of performance, losing efficiency and flexibility, and difficulty and complexity
in the system.
6.2 Necessary Conditions for a Good Database Design

The database should be able to solve the issues that happen on the real-world structure
and have the ability to represent any type of data that are accepted in the system. It
should have a good consistency and avoid redundancy. Moreover, the data in the
database should be accessible at any time without regarding geographical location.
Furthermore, the maintenance of data integrity should be supported over time.
6.3 Four Steps in Database Design Process

There were four steps involved in the processing and development of the database
design. Those steps started with requirement gathering, followed by conceptual
design, then logical design, and the final step was physical design.
(i) Requirement Analysis
(ii) Conceptual Design
(iii) Logical Design
(iv) Physical Design

These steps will be discussed in the rest of this section.

6.3.1 Requirement Analysis:

At this stage, we break down our grand idea into smaller and more manageable
chunks of functionality. This step is related to determining, gathering, and organizing
the requirements. Therefore, in Chapter 3 all requirements were gathered and
provided. The aim of performing such a step is to allow the designer to sketch the
conceptual design of the system. Ensuring accuracy during the collection of

32
requirements means that the design will be efficient, flexible, and easy to maintain. To
provide a good accuracy in the requirements stage, some techniques can be performed
during this step, such as taking the advantages from previous projects, teachers, and
students' demands, and visiting existing websites.

6.3.2 Conceptual Design:

It is a process of constructing a data model for each view of the real world problem
which is independent of physical considerations. In this step of the database design
process, ER modeling is used for understanding and representing the meaning of the
system. Moreover, this model is used to help the developers to understand the
information which should be stored in the system. Furthermore, it is used to show the
data storage's logical structure to the developers. For this reason, an ER diagram is
used to sketch the conceptual design of the system.

6.3.2.1Entity Relationship Diagram (ERD):

Entity Relationship Diagram is used to represent the structure of the database design
graphically which is simple and clear. This diagram is used by most designers in order to be
helpful for developers while enabling them to understand the system design quickly and
easily. In this project, an Entity Relationship Diagram is used for expressing the structure of
the system design. The ERD diagram can be found in the chapter 5.

6.3.3 Logical Design:

In this phase of the database design, a model of information will be established and
supported by the database management system to locate into the storage object. In this
phase two steps are involved. The first step is the creation of tables from the ER
model, and the second step is to normalize the tables.

6.3.3.1 Normalization:

Normalization is a process of increasing the normal form rating. Effective database

designers will keep in mind the principles of normalization while they design a
database. In this design, normalization was used to avoid redundancy and data
anomalies. By doing so, the efficiency of the system will be increased because the
amount of data will be decreased remarkably compared to that in the system without

33
the normalization. Moreover, using such a technique during the design of this system
means that the reduction of data restructuring can be considered, as well as the
obligatory in maintenance of foreign key will be noticed.

6.3.3.1.1 Un-normalized Table (PRODUCT)

Product Product Type Weight Description Price Image
ID Name (KG) (PKR)
101 CM3 Key 6 Sensor key 28000 Nil
Coder for Programmer programming
BMW device.
102 G5 Launch 11 -------- 90000 Nil
Diagnostic Accessories
103 Launch X- Launch 25 Diagnostic 135000 Nil
431 Accessories device for all
vehicles.

Table 6.1: Un-normalized table of products with repeating values.

The above table is not normalized and contains repeating values for product type, so
we need to apply 1st normal form on this table.

6.3.3.1.2 1st Normal Form:

The table split in to two tables (PRODUCT and CATEGORY) to overcome repeating value.

a. Table : PRODUCT
Product ID Product Name Weight (kg) Description Price

1 Key programmer 20 Good tool 499

2 Launch X-431 12 Latest 299

3 Odo meter 9 Heavy Vehicle 899

4 Code Reader 6 For BENZ 888

Table 6.2: 1st Normal Form, table product.

34
 b. Table : CATEGORY

Category ID Category Name

1 Launch Accessories

2 Code Readers

3 Car Scanners

Table 6.3 1st Normal Form, table category.

6.3.3.1.3 2nd Normal Form:

In second normal form a category id is added to the product table.

Product Category Product Name Weight Description Price

ID ID (kg)

1 1 Key 20 Good tool 499

programmer

2 2 Launch X-431 12 Latest 299

3 3 Odo meter 9 Heavy 899

Vehicle

4 4 Code Reader 6 For BENZ 888

Table 6.4: 2nd Normal Form, table product.

35
Hence the Product table is now normalized. In our project some of other tables like
users, products, orders, etc contains very short attributes and tables are already
normalized so there was no need to further normalize them. Attributes of each table
are described in data dictionary just next to the paragraph.

6.3.3.2 Data Dictionary of the Project:

1. Product:

Field Name Data Type Field Size Property

Product_ID Int 11 Primary key

Product_Name Varchar 100

Category_ID Int 11 F.K

Weight Varchar 10

Description Varchar 512

Price Float 10

Product_image Varchar 500

Table 6.5: data dictionary of table product.

2. Category:

Field Name Data Type Field Size Property

Category_ID Int 11 Primary Key

Category_name Varchar 30

Table 6.6: data dictionary of table product category.

36
 3. Order:

Field Name Data Type Field Size Property

Order_ID Int 11 Primary Key

Product_ID Int 11 F.K

Order_Quantity Int 11

Total_Cost Float 10

Order_Date Date

Sender_Email Varchar 30

Sender_Contact Int 20

Table 6.7: data dictionary of table product order.

4. User:

Field Name Data Type Field Size Property

U_ID Int 11 Primary Key

Email Varchar 30

Contact Int 25

Address Varchar 500

Password Varchar 30

Reg_Date Date

Table 6.8: data dictionary of table user.

37
6.3.4 Physical design:

After finishing the logical database design phase, the physical database design begins
in order to convert the logical phase into physical implementation. This phase starts
with applying the first normal form concept on the logical ERD, in which entities will
be converted into tables and attributes into fields. In addition, a primary key will be
applied to each table. After that, the second normal form will be applied into the
logical ERD, in which foreign keys will be created to combine tables together.
Finally, the third normal form will be applied, in which the constraints and defaults
will be determined as the business rule in the designing database process. After
deploying the web-based system, the physical model will be changed when the system
needs to be extended, maintained, or enhanced. Moreover, increasing new features of
the system is related to change in the physical phase.

38
 6.4 The Database Diagram of the System

ProductSold
ID

InvoiceNo Invoice_Info
ProductID InvoiceNo

ProductName InvoiceDate

Quantity SubTotal

Price VATPer

TotalAmount VATAmount

DiscountPer

DiscountAmount

GrandTotal
SubCategory
Cash
ID
Change
SubCategoryName

CategoryID Product
ProductID Stock
ProductName StockID

CategoryID ProductID

SubCategoryID Quantity

Features StockDate

Price

VAT
Category
ST
ID Temp_Stock
Discount
Categoryname ProductID
Photo
Quantity
Image

Figure 6.1: Database Diagram.

39
CHAPTER 7

FRAMEWORK
7.1 Framework
.NET Framework (pronounced dot net) is a software framework developed by
Microsoft that runs primarily on Microsoft Windows. It includes a large class library
known as Framework Class Library (FCL) and provides language interoperability
(each language can use code written in other languages) across several programming
languages. Programs written for .NET Framework execute in a software environment
(as contrasted to hardware environment), known as Common Language Runtime
(CLR), an application virtual machine that provides services such as security, memory
management, and exception handling. (As such, computer code written using .NET
Framework is called "managed code".) FCL and CLR together constitute .NET
Framework.
FCL provides user interface, data access, database connectivity, cryptography, web
application development, numeric algorithms, and network communications.
Programmers produce software by combining their own source code with .NET
Framework and other libraries. .NET Framework is intended to be used by most new
applications created for the Windows platform. Microsoft also produces an integrated
development environment largely for .NET software called Visual Studio.
.NET Framework started out as a proprietary framework, although the company
worked to standardize the software stack almost immediately, even before its first
release. Despite the standardization efforts, developers – particularly those in the free
and open-source software communities—expressed their uneasiness with the selected
terms and the prospects of any free and open-source implementation, especially with
regard to software patents. Since then, Microsoft has changed .NET development to
more closely follow a contemporary model of a community-developed software
project, including issuing an update to its patent promise to address the concerns.
.NET Framework lead to a family of .NET platforms targeting mobile computing,
embedded devices, alternative operating systems and browser plugins. A reduced
version of the framework, .NET Compact Framework, is available on Windows CE
platforms, including Windows Mobile devices such as smart phones. .NET Micro
Framework is targeted at severely resource-constrained embedded devices. Silver
light was available as a web browser plugin. Mono is available for many operating
system and is customized into popular Smartphone operating systems (Android and

40
iOS) and game engines. .NET Core targets cross-platform and cloud-based workloads
in addition to the Universal Windows Platform (UWP).
7.2 Visual Languages

In computing, a visual programming language (VPL) is any programming language

that lets users create programs by manipulating program elements graphically rather
than by specifying them textually. A VPL allows programming with visual
expressions, spatial arrangements of text and graphic symbols, used either as elements
of syntax or secondary notation. For example, many VPLs (known as dataflow or
diagrammatic programming)[3] are based on the idea of "boxes and arrows", where
boxes or other screen objects are treated as entities, connected by arrows, lines or arcs
which represent relations.
7.3 Visual C#
Microsoft C# (pronounced C sharp) is a new programming language designed for
building a wide range of enterprise applications that run on the .NET Framework. An
evolution of Microsoft C and Microsoft C++, C# is simple, modern, type safe, and
object oriented. C# code is compiled as managed code, which means it benefits from
the services of the common language runtime. These services include language
interoperability, garbage collection, enhanced security, and improved versioning
support.
C# is introduced as Visual C# in the Visual Studio .NET suite. Support for Visual C#
includes project templates, designers, property pages, code wizards, an object model,
and other features of the development environment. The library for Visual C#
programming is the
7.4 Advantages

Visual C# .NET (pronounced Visual C sharp) is Microsoft's new-generation

programming language that integrates the flexibility of C++ with the short
development cycle of Visual Basic. These features, along with an array of new
features, make Visual C# more than just the sum of Visual Basic and C++.

41
Some of the features of Visual C# are

 Garbage collection: The function of the garbage collector, provided by Visual

C#, is to check for the objects not being used by an application and to delete them
from memory.

 Value/reference type system: According to the value/reference type system, the

standard data types, enumerations, and structures are called value types.
Interfaces, classes, and delegates are called reference types. This type system
provides the advantage of eliminating a number of memory bugs and simplifying
object manipulation.

 Unified declaration and definition of class methods: The unified declaration

and definition of class methods alleviates you from creating multiple files — one
for declaration and the other for definition.

 Delegates: A type-safe and secure object that contains a reference to a method.

The advantage of using delegates is that it is helpful in anonymous invocation,
which means that the method to be invoked is not known at compile time.

 Simple thread synchronization: Enables you to create multithreaded

applications.

 Versioning: You need to explicitly override the members of a base class in a

derived class. This revision creates a new version without affecting the existing
program.

 Interoperability: Visual C# applications are platform-independent.

 Access to native-code: Visual C# allows a developer to programmatically view

the native code.

 Attributes: A declarative tag that you can use to describe various entities in your
programs

42
 CHAPTER 8

DATABASE MANAGEMENT SYSTEM

8.1 Relational database management systems (RDBMS)

Because the computer has become an important part of people's lives and plays a role
in most aspects of their lives, they use it to store and protect their information. This
part of the report focuses on RDBMS but before discussing this, the terms 'database'
and 'DBMS' should be defined.

A database can be defined as a data structure that is used for storing organized
information. Relational databases contain a number of tables, each table includes
various fields. Databases have dramatically changed compared to those found in
earlier decades because in the past, databases were relatively "flat," which means that
they just contained some rows and columns and were used for storing plain text fields.
Nowadays, however, there are many types of relational databases that store data in a
more logical structural way, such as PostgreSQL, MySQL, Oracle, and Microsoft
SQL Server.

A software program which is used to administrate data in a database called RDBMS.

According to the data structure or type, DBMS will be changed. DBMS has many
advantages that can be considered, such as building a better strategic way of using
consistent data. In addition, it eliminates or reduces ambiguity in the administration of
information, has better security, integrity enhancement and increases the flexibility of
the information system

RDBMS built on the relational model and stands for Relational Database
Management System. Currently, the relational database model was considered in
building majority of the open source databases. There are many RDBMS, such as
Sybase, Oracle, Microsoft, DB2, MS SQL, PostgreSQL, and MySQL.

In this project, there is a lot of data that should be organized, and then accessed by
different users, for this reason, this subsection focuses on RDBMS. Two types will be
discussed here: SQL Server 2008. Firstly, each of these types will be described, and
then a comparison will be made between them. Finally, the decision will be made
about choosing one of these types to use in this project.

43
8.2 SQL Server

Microsoft SQL Server is a relational database management system developed by

Microsoft. As a database server, it is a software product with the primary function of
storing and retrieving data as requested by other software applications—which may
run either on the same computer or on another computer across a network (including
the Internet).

Microsoft markets at least a dozen different editions of Microsoft SQL Server, aimed
at different audiences and for workloads ranging from small single-machine
applications to large Internet-facing applications with many concurrent users.

8.3 SQL Server Management Studio

SQL Server Management Studio is a GUI tool included with SQL Server 2005 and
later for configuring, managing, and administering all components within Microsoft
SQL Server. The tool includes both script editors and graphical tools that work with
objects and features of the server. SQL Server Management Studio replaces
Enterprise Manager as the primary management interface for Microsoft SQL Server
since SQL Server 2005. A version of SQL Server Management Studio is also
available for SQL Server Express Edition, for which it is known as SQL Server
Management Studio Express (SSMSE).

A central feature of SQL Server Management Studio is the Object Explorer, which
allows the user to browse, select, and act upon any of the objects within the server. It
can be used to visually observe and analyze query plans and optimize the database
performance, among others. SQL Server Management Studio can also be used to
create a new database, alter any existing database schema by adding or modifying
tables and indexes, or analyze performance. It includes the query windows which
provide a GUI based interface to write and execute queries.

44
 CHAPTER 9

IMPEMENTATION AND TESTING

9.1 Implementation and Testing

After considering the functional and non-functional requirements (Chapter 3), the
design of the system (Chapter 4), and the use of various technologies (Chapter 2), the
MIS of Shop system was implemented. This chapter starts with sketching the system
interface architecture. Then the development of the user interface will be discussed,
based on the structure mentioned in the earlier chapter. Following this, the rest of this
chapter will focus on implementing the functional requirements.
9.2 User Interface Implementation

C# was used to develop the User interface. During this development, there was a
focus on the principles and structures, as was discussed in the User interface section
of the System Design chapter. In this section, the development of the User interface
will be discussed and the relevant code and the user interface will be presented.
9.3 Implementation of Functional Requirements

As discussed in earlier chapters, the functional requirements are divided into

system requirements and user requirements. In this section, the implemented
functional requirements will be discussed and the relevant code for the user
interface will be presented.
9.4 Implementation of System requirements

9.4.1 Authentication and Authorization:

The system offers a restricted authentication process. To access the system, users
must be registered in advance. Since the system can be used by different users will be
registered by the system administrator.

Registered users can access the system by using their email and password. The system
comprises two steps to specify the authentication and authorization of each user. The
first step is to check the email and password to specify whether or not the user is a
member, if they are not a member, a warning message will appear.

Validation is an important aspect of the system. When the new member is sign up to
the system, he must enter the full name, email, contact, address and password. Also,
in order to enter accurate information, the system will guide them through the

45
appearance of messages when they move the mouse over buttons besides the required
text fields. When users are entering enter a wrong input the pop up alert will appear
and gives alert of invalid account this means that the input is not valid. When they are
entering a right input, the color will change into a light blue and green border, which
means that the information is right and accurate. However, if all information is valid
and the sign up button is clicked, the system checks for the registration id and the
email; if one of these already exists in the system, a message will appear to ask them
to try again
9.5 Testing

There has been a growth in the web-based system development in recent years; these
are now involved in almost all aspects of life today. Web-based systems can be
criticized by their users, but also loopholes, gaps and deficiencies can be found by
hackers and attackers.

Therefore, to avoid those criticisms and risks, testing must be carried out. In this
chapter functional and non-functional testing will be discussed. At first, different
definitions will be presented and the two types of system testing will be discussed.

Testing is a process used to evaluate a system's ability and to specify that it has met
the requirements.

The testing process is the way of disclosing the advantages and the risks associated
with the system when it is deployed. There are different testing types: white box
testing and black box testing. In this chapter, both types will be introduced, evaluated
and compared.

9.5.1 White Box Testing:

White box or glass-box testing focuses on the structure of the system and code tests.
In this type of testing, the testers should be technical. White box testing helps to
identify the logical and coding issues. Unit testing is a type of white box testing

White box testing strategy emphasizes on examining the procedural details of a

software system or component. This sort of testing deals with measuring the logical

46
complexity in the procedural design of system. The test cases designed need to be
guaranteed to execute every statement in the program at least once.

A common strategy used for white box testing is Basis Path Testing. Path Testing is
the white box testing strategy whose objective is to execute every independent path of
the component/procedure. The starting point for white box testing is the flow graph
.The Flow Graphic skeletal model of all paths through a program. A flow graph
consists of nodes and edges, nodes represent decision and edges represent flow of
control.

The Cyclamate Complexity is software metric that provides a quantitative measure of

the logical complexity of program. When used in context of basic path testing method
the value computed for cyclamate complexity defines number of independent paths.

9.5.2 Black Box Testing:

Black box testing focuses on full functional requirements tests. This type of testing
does not address logical and coding issues. Both types of system testing and
acceptance testing are examples of black box testing. In this type of testing, both non-
technical and technical testers can test the system. Those testers specify the vagueness
and contradictions found in functional specifications.

Black box testing (also called functional testing) is testing that ignores the internal
mechanism of a system or component and focuses solely on the outputs generated in
response to selected inputs and execution conditions. It focuses on the functional
requirements of the software but it is also useful for determining non-functional
requirements. It applies on the inputs of the system. Black box testing is rottenly used
for validation (are we building the right application?). Black box testing attempts to
find errors in following categories:

 Incorrect or missing functions

 Interface errors

 Errors in data structures or external database access

 Behavior or performance errors

47
  Initialization and termination errors

In the black box testing system can be considered as a black box.

Correct input Error input test

test data data

My Application

Correct Result Output that contain

some error

Figure 9.2: Black Box Testing.

48
 CHAPTER 10
USER INTERFACE
10.1 Splash Screen

Figure 10.1: Splash Screen

10.2 Admin Login

Figure 10.2: Snapshot of Admin Login Form.

49
10.3 Main Form

Figure 10.3: Main Form

10.4 View Category

Figure 10.4: View Category

50
10.5 Add Category

Figure 10.5: Add Category

10.6 Stock Record

Figure 10.6: Stock Record.

51
10.7 Add Stock

Figure 10.7: Add Stock

52
 REFERENCES
1. Jaffery A Hoffer, Mary B Prescott & Fred R McFadden - Modern Database
Management (Eighth Edition).

2. Modern Data Base IT Series

3. Rojer Pressman - Software Engineering Fifth Edition

4. Professional C# 5.2 by Ed Lecky-Thompson, Steven D. Nowicki, and

Thomas Myer.

5. Beginning C# and SQL: From Novice To Professional By W. Jason Gilmore.

6. Software engineering A Beginner’s Guide, 2nd Edition by Wendy Willard.

53