Final Documentation For Lub

Final Project
Distributed Lubricant Sale Point System
Contents
Chapter# 1 Requirements Analysis & Specification ..................................................................................... 7
1.1 Introduction .............................................................................................................................. 8
1.2 Existing system and Fesibility Report ...................................................................................... 8
1.2.1
Feasibility Report ................................................................................................... 8
1.2.2 Technical feasibility ................................................................................................... 9

1.2.3 Economical feasibility .................................................................................................. 9
1.2.4 Legal feasibility .......................................................................................................... 10
1.2.5 Operational feasibility ............................................................................................... 10
1.2.6 Schedule feasibility.................................................................................................... 11
1.2.7 Specification feasibility ............................................................................................ 11
1.2.7 Informational feasibility ............................................................................................ 12
1.2.8 Motivational feasibility.............................................................................................. 12
1.2.9 Is project Feasible or not? ......................................................................................... 12
1.3 Problem Statement ................................................................................................................ 12
1.4 Objective & Goals ................................................................................................................ 13
1.5 Project scope ......................................................................................................................... 13
1.6 Proposed System ................................................................................................................... 14
1.7 User Classes .......................................................................................................................... 14
1.8 Operating Environment ........................................................................................................ 15
1.8.1 Hardware Interface ................................................................................................... 15
1.8.2 Software Interface ..................................................................................................... 15
1.9 Design and Implementation Constraints .............................................................................. 15
1.10 User Documentation .......................................................................................................... 16
1.11 Assumptions and Dependencies ......................................................................................... 16
1.12 System Features ................................................................................................................. 16
1.12.1 Accuracy and Security: ........................................................................................... 16
1.12.2 Universality: ............................................................................................................ 16
1
Final Project
1.12.3 Environment friendly: ............................................................................................. 17

1.13 Non-Functional Requirements ........................................................................................... 17
1.13.1 Performance Requirements ..................................................................................... 17
1.13.2 Safety Requirements ............................................................................................... 18
1.13.3 Security Requirements ............................................................................................ 18
1.13.4 Software Quality Attributes .................................................................................... 18
1.13.5 Business Rules......................................................................................................... 18
1.14 Other Requirements .............................................................................................................. 19
1.15 Proposed Model .................................................................................................................... 19
1.15.1 Ittrative Waterfall Model.......................................................................................... 19
1.15.2 Why we have used waterfall Model? ....................................................................... 20
Chapter#2
User Interface & Database Design ......................................................................................... 21
2.1 System Design ....................................................................................................................... 22

2.1.1 Class Diagram ............................................................................................................ 23
2.1.1 Relational Class diagram of server side...................................................................... 24
2.1.2 Relational Class diagram of Client side ...................................................................... 25
2.1.3 Inheritance and Generalized Class diagram of server side ........................................ 26
2.1.4 Inheritance and Generalized Class diagram of client side ....................................... 27
2.2 Use Cases................................................................................................................................ 27
2.2.1 Main System module Use Case Diagram .................................................................. 28
2.2.2 Add Record Use case module For Administrator ...................................................... 29
2.2.3 Delete Record Use case module For Administrator .................................................. 30
2.2.4 Update Record Use case module For Administrator ................................................. 31
2.2.5 View Record Use case module For Administrator .................................................... 32
2.2.6 Add Record Use case module For Operator .............................................................. 33
2.2.7 Delete Record Use case module For Operator .......................................................... 34
2.2.8 Update Record Use case module For Operator ......................................................... 35
2.2.9 View Record Use case module For Operator ............................................................ 36
2.3 Sequence Diagram ................................................................................................................ 37
2.3.1 Log in ........................................................................................................................ 38
2
Final Project
2.3.2 Manage Stock ............................................................................................................ 38

2.3.3 Generate invoice:....................................................................................................... 38
2.3.4 Generate stock report: ............................................................................................... 39
2.3.5 Generate Supplier Report: ......................................................................................... 39
2.4 Activity Diagram ................................................................................................................. 40
Chepter #3 Coding and Snapshots ........................................................................................................... 41
3.1 Login Module ....................................................................................................................... 42
3.1.1 Coding .................................................................................................................... 42
3.2 Menu Module ..................................................................................................................... 45
3.2.1Coding ...................................................................................................................... 45
3.3 Category Module ................................................................................................................. 57
3.4 Item Details Module........................................................................................................... 57
3.5 Customer Module ................................................................................................................ 58
3.6 Employee Module ................................................................................................................ 58
3.7 Sale Module ......................................................................................................................... 59
3.8 Supplier Module .................................................................................................................. 59
3.9 Feedback Module................................................................................................................. 60
3.10 Send Promotion Module .................................................................................................... 60
3.11 User Wizard ..................................................................................................................... 61
Chapter#4 Testing ...................................................................................................................................... 62
4.1 Introduction .......................................................................................................................... 63
4.2 Unit Testing .......................................................................................................................... 63
4.3 Integrated Testing ................................................................................................................. 63
4.4 Subsystem and System Testing............................................................................................. 63
4.5 Black Box and White Box Testing ....................................................................................... 64
4.6 Test cases with black box tests ............................................................................................. 64
4.6.1 Test Case 1: Login .............................................................................................. 65
4.6.2 Test Case 2: Category ......................................................................................... 66
4.6.3 Test Case 3: Manage Items ................................................................................. 66
4.6.4 Test Case 4: Customer ........................................................................................ 67
3
Final Project
4.6.5 Test Case 5: Sales ............................................................................................... 67

4.6.6 Test Case 6: Reports ........................................................................................... 68
4.6.7 Test Case 7: Send Promotions ............................................................................ 68
4.6.8 Test Case 8: Tools ............................................................................................... 69
4.6.9 Test Case 9: Feedback......................................................................................... 69
4.6.10 Test Case 10: Employee ...................................................................................... 70
Bibliography ................................................................................................................................................ 71
Final Project
List of Figures:
Fig 1.1: Itrative Waterfall Model20
Fig 2.1 Relational Class Diagram of server side.24
Fig 2.2 Relational Class Diagram of client side..25
Fig 2.3 Inheritance and Generalized Class Diagram of server side26
Fig 2.4 Inheritance and Generalized Class Diagram of server side27
Fig 2.5 Use Case Diagaram.28
Fig 2.6 Add Record Use case modules For Administrator..29
Fig 2.7 Delete Record Use case modules For Administrator 30
Fig 2.8 Update Record Use case modules For Administrator.31
Fig 2.9 View Record Use case modules For Administrator32
Fig 2.10 Add Record Use case modules For Operator33
Fig 2.11 Delete Record Use case modules For Operator34
Fig 2.12 Update Record Use case modules For Operator..35
Fig 2.13 View Record Use case modules For Operator.36
Fig 2.14 Sequence Diagram.37
Fig 2.15 Activity Diagram.. 40
Fig 3.1 Login Module..42
Fig 3.2 Menu Module..45
Fig 3.3 Category Module57
Fig 3.4 Item Details Module57
Fig 3.5 Customer Module...58
Fig 3.6 Employee Module..58
Fig 3.7 Sale Module59
Fig 3.8 Supplier Module.59
Fig 3.9 Feedback Module60
Fig 3.10 Send Promotion Module60
5
Final Project
Fig 3.11 User Wizard Module..61
List of Tables :
Table 1.1: Economical feasibility...09
Table 1.2: Schedule feasibility...11
Final Project
Chapter# 1
Requirements Analysis & Specification
Final Project
1.1 Introduction
In our modern society everyone is attach to new technology and want friendly environment
in their organization. Khawaja Autos is located in Kotli Azad Kashmir. I purposed a system that
manages their records related to Lubricant, employees, salaries and companies record. We
propose level of logins for admin and operator. Operators have limited access area but admin can
access everything in this softwar.
1.2 Existing system and Fesibility Report

The existing Lubricant system of Khawaja auto is traditionally manual. It is totally paper
work. Admin have lot of problem to maintain the whole lubricant records. It is difficult to
maintain the baranch record in manual system.
1.2.1
Feasibility Report
Our proposed system is distributed sale point system for Khawaja autos. The system will
only be effectively implemented when it is feasible for the users. An estimate is of whether the
identified user needs may be satisfied using current system and hardware technologies. This
study besides developed under given budgetary constraints.
This report will make the comparison between the old system and new system. A system
request must need several tests to see whether it is worthwhile to proceed further. This series of
test called feasibility study and it is the virtual part of every system. This feasibility report
include following:
O Technical Feasibility
O Economical Feasibility
O Legal Feasibility
O Schedule Feasibility
O Specification Feasibility
O Information Feasibility
O Motivational Feasibility
O Is project feasible or not?
8
Final Project
1.2.2 Technical feasibility

Technical feasibility is carried out to determine whether the organization has the capability,
in terms of application, hardware, personnel and expertise, to handle the completion of the
project. We will use C# for designing interface because of its drag and drop features. C# includes
new languages features, objects oriented approach, and enterprise application and more complete
integration with software development kit and .net framework kit. The user will use the proposed
system widely. The system is performing properly. These tools will provide feasible interface
for the users. The interface of this application is user friendly. Every user will use this
application easily.
1.2.3 Economical feasibility

Economical feasibility means whether the cost of use of any software in the development
process, implementation of the application, maintenance of the system and technical training of
the system is economical for the user or not. Economic analysis is the most frequently used
method for evaluating the effectiveness of a proposed system.
Economically this application is feasible for all users. It is easy to manage the activities
while using the new application the cost of the new application is reasonable for the users and
requirements could easily be available in different systems using distributed technology. The
benefit of the system is more than its cost so the implementation is easy and beneficial.
Infrastructure
Cost(PKR)
.net frame work
1000
Sqlserver
Free
Microsoft office
Free
PC cost
40,000
Webserver Domain
1000 Per year
Total
42,000
Table 1.1: Economical feasibility
Final Project
1.2.4 Legal feasibility

A legal feasibility will tell whether the development of the system would violate any set of
rule and regulations defined. System is an intellectual property, so legal feasibility also arises.
All organizations have some such information, which has to keep secret and is confidential, so
we will try our level best to keep all such information secret.
1.2.5 Operational feasibility

Is a measure of how well a proposed system solves the problems, and takes advantages of
the opportunities identified during scope definition?
The proposed system will meet increasing future needs.
The existing system is manual so the proposed application solves the problem of time
consumption.
It will provide friendly environment to user to maintain sale records.
Proposed system will provide a user friendly interface for interaction.
10
Final Project
1.2.6 Schedule feasibility

Typically this means estimating how long the system will take to develop. Proposed system
will be completed before 1 Jan 2015.
Task:person\weekly
10
11
A:Rizwan Tabassum
B:Rizwan Amjad
C:Sajjad Amhed
D:Rizwan Tabassum
E:Naveed Saeed
F:NaveedSaeed/Sajjad Amhed
G:Naveed Saeed
H:NaveedSaeed/Sajjad Ahmed
Table 1.2: Schedule feasibility
Activity key:
A: Specifying Module1
F: Coding Module2
B: Specifying Module2
G: Integration Testing
C: Design Module1
H: System Testing
D: Design Module2
E: Coding Module1
1.2.7 Specification feasibility

System specification i.e., hardware and software are mentioned in the proposal. Scope is
also mentioned in the proposal, which compasses
(1) Analyze, collect and define high level needs and features of the proposed application.
(2) Focus on the needs and capabilities of the stack holders.
11
Final Project
1.2.7 Informational feasibility

For the completion of the project resource person will provide all the necessary and required
information.
1.2.8 Motivational feasibility

Our team is motivated by our project supervisor to work on this project. Using C#
technology, which is provide friendly environment to complete this project, So that is why we
are very optimistic and motivated to do this project that we will be able to compete with the
market.
1.2.9 Is project Feasible or not?

We can found that we have introduced a successful distributed sale point system. We
realized that our findings and researches can authentic to a large extent. We found it easily
followed by the group of people for which we recommended it. This is easy to access as it is
simple, cheap, user friendly and easily available. We hope that this application provide an easy
way to user to maintain its sale records.
1.3 Problem Statement

Khawaja autos have many branches in different places and there are lots of issues related to
maintain the records of lubricants, there employees, their salaries record and sales record etc. All
existing manual solution takes more time and efforts to sort out these problems.
The problems related to existing systems are:
Difficult to maintain different branches records.
In Traditional file base system there are lot of problem to maintain records and stabile the
records
No proper way to manage the staff salary records.
Traditional file system is not secure. The sale man can easily change the sale records.
No proper way to the stock records.
12
Final Project
All these type of problems, we discus in our project. In manual system it takes lots of effort and
is time consuming
1.4 Objective & Goals

Login System for Admin and User.
Keep and update record of Sales.
Manage Supplier Details.
Manage Stock.
Manage companies record.
Manage Employees record
Manage Salary system for employees.
Reports
o Bills
o Salary Slips
o Overall Lubricant Information
o Stock Reports
o Sales Reports
1.5 Project scope

The scope of our project is to provide an easy way to handle the lubricant information,
maintain the log of both admin and user, records of sales, mange supplier details, maintain the
stock, manage employees records and also manage the salary system of employees. We also
provide the friendly environment to generate the details report of bills, pay slips, stock reports
and sales report of Khawaja autos.
13
Final Project
1.6 Proposed System

We propose Sale records management system for Khawaja autos. The solution is to define
all rules separated with respect to their Criteria.
Our propose solution have:
Login System for Admin and User.
Keep and update record of Lubricants.
Keep and update record of Sales.
Manage Supplier Details.
Manage Stock.
Manage companies record.
Manage Employees record.
Manage Salary system for employees.
Reports
o Bills
o Salary Slips
o Overall Lubricant Information
o Stock Reports
o Sales Reports
1.7 User Classes

The system provides different types of services based on type of users. The staff will be
acting as a controller and he/she will have all the privileges of an administrator.
There are various kinds of users for the product. Usually the sale point system can be access by
various users for different reasons.
The users include:
Admin who will be acting as the controller.
S t a f f s t h a t w i l l b e u s e the sale point system in different shops and their sales
record admin can see.
14
Final Project
1.8 Operating Environment

1.8.1 Hardware Interface
The Hardware Requirements specify:
Pentium 3 or Higher Processor Minimum Speed 2.4GHZ.
Hard disk of 10GB capacity or more.
Minimum 1GB RAM or higher.
Standard output display with color resolution scheme 1280/768.
1.8.2 Software Interface

The Software Requirements specify:
Microsoft Windows 7, 8 or Service Pack 3.
SQL 2008 should be installed.
Visual Studio 2012.
1.9 Design and Implementation Constraints

The following list presents the constraints, assumptions, dependencies or guidelines that are
imposed upon implementation of the Distributed Lubricant Sale Point System:
The software must be able to identify all the devices that will be connected against the
software.
The product must have a user friendly interface for the checking purpose that is simple
enough to understand.
Response time for loading the software and for processing a transaction should be no
longer than five seconds.
A general knowledge of basic computer skills and of basic working of Distributed

Lubricant Sale Point System is required to use the product.
15
Final Project
1.10 User Documentation

The product will include user manual. The user manual will include product overview,
complete configuration of the used software (such as SQL server), technical details, backup
procedure and contact information which will include phone number or email address. The
product will be compatible with windows desktop application.
SRS in MS- Word.
Microsoft Visual Studio 2012 for Application Creation.
The databases will be created in the Microsoft SQL server 2008.
Project design in MS- Visio.
Presentation in PPT.
1.11 Assumptions and Dependencies
When the main source of power is off, there will be alternative source.
If one sale point is failed, they cannot be effect by other shop sale point records.
If the system is corrupted, there is a backup and the proctor can easily restore it.
If server is crash there may be alternative way to handle the record.
1.12 System Features

1.12.1 Accuracy and Security:
Whole records can be secure so that in traditional file base there are lot of security issue
such as losing of data. Our purpose system whole data can maintain securely and accurately.
1.12.2 Universality:
Everyone has a log feature and it is thus universal to staff members.
16
Final Project
1.12.3 Environment friendly:

The GUI of the system is user friendly and it reduces paper and other resource requirement
and does not cause any negative impact to the environment.
Some of other features are:
Secure Login.
Maintaining Record of Lubricant.
Maintaining Employees.
Manage Salaries.
Manage Sales.
Manage Companies.
Search Sales Record any time.
Search Employee detail any time.
Salary slips.
Bills.
Stock Information.
Employee Information.
1.13 Non-Functional Requirements

1.13.1 Performance Requirements
The software is designed for Distributed Lubricant Sale Point Management System to
reduce the old traditional file base system.
The software will install on different locations but whole record can be maintaining one
server.
All textual information will be handled by the software.
For normal conditions, 95% of the transactions should be processed in less than 5
seconds.
17
Final Project
1.13.2 Safety Requirements

The database may get crashed at any certain time due to virus or operating system failure.
Our purpose system can provide the backup of whole records. In any time system will crashed it
is required to take the database backup.
1.13.3 Security Requirements

We are going to develop a secured Distributed Lubricant Sale Point System for Khawaja
autos. There are different categories of users namely Operator and administrator depending upon
the category of user the access rights are decided. It means if the user is an administrator then he
can be able to modify the data, delete, append etc., all other users other than admin have the
rights to retrieve the information of Operator and Operator have the rights to retrieve the
information of customer from database.
1.13.4 Software Quality Attributes

The Quality of the sale point system and there database is maintained in such a way so that it
can be very user friendly to all the users of the database.
Our software product quality attribute are:
Main quality of our project is to saving lot of time of user to maintain the whole records
of all shops.
The quality of database is maintained in such away so that it can be very user-friendly to
the all user of database.
System can provide fastest way to generate the report of each record quickly.
Secure system, no one Operator can update his/her own record.
Easy to install the system.
1.13.5 Business Rules

A business rule is anything that can be capture and implements business policy and
practices. A business rule can enforce the business policy, make a decision, or infer data from
existing data. These include the rules and regulation that the system user should abide by. These
18
Final Project
include the cost of project and the discount offers provided. The user should avoid the illegal
rules and protocols. Neither admin nor member should cross the rules and regulations.
1.14 Other Requirements

None.
1.15 Proposed Model

A software process model is an abstract representation of software process. Each
process represents a process from particular perspective so only provides particular
information about the process.
Software lifecycle models play an integral role in software products. They help to create
stable, correct product that meet user's needs. There are a variety of software lifecycle
models, but the best one proposed system is "Waterfall Model".
1.15.1 Ittrative Waterfall Model

The Ittrative Waterfall model can also be thought of the classic lifecycle model. It was
introduced in early 70s to help make the process of the software development more
structured. It is a very sequential, organized approach to software development and is still
the most widespread model used today.
The major phases of Ittrative waterfall model are as follows:
Requirement Analysis.
Design.
Coding.
Testing.
Implementation.
Maintenance.
19
Final Project
Fig 2.1: Itrative Waterfall Model
1.15.2 Why we have used waterfall Model?

We use waterfall model because:
It is simple model for software development.
It provides a template into which methods for analysis, design, coding, testing and
support can be placed.
All requirements, related to our software we specified first, so this model is best for
selection when there are no complex requirements are specified first.
Our software is not larger one, so it does not create requirement problems.
20
Final Project
Chapter#2
User Interface & Database Design
21
Final Project
2.1 System Design

The System Design phase is the most important phase in the development of a system. The
logical system design arrived at as a result of system analysis and is converted into physical
system design. In the design phase the system development life cycle process continues to move
from what question of the analysis phase to the how. The logical design produced during the
analysis is turned into a physical design which is a detailed description of what is needed to solve
original problem. Input, output, databases, forms, codification schemes and processing
specifications are drawn up in detail. In the design stage, the programming language and the
hardware and software platform in which the new system will run are also decided. Data
structure, control process, equipment source, workload and limitation of the system, Interface,
documentation, training, procedures of using the system, taking backups and staffing
requirement are decided at this stage. Here the logical design is done through following
diagrams:
Class Diagram
Use Case
System sequence
Activity
Physical design produces the working system by defining the design specifications,
which tell the programmers exactly what the candidate system must do. The
programmers write the necessary programs that accept input from the user, perform
necessary processing on accepted data through call and produce the required report on a
hard copy or display it on the screen.
22
Final Project
2.1.1 Class Diagram

A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them.
There are two principle kinds of static relation
Association and subtype class diagrams also show attributes and operations of a class and the
constraints that apply to the way objects are connected. In software engineering, a class diagram
in the Unified Modeling Language (UML) is a type of static structure diagram that describes the
structure of a system by showing the systems classes, their attributes, and the relationships
between the classes.
A class has three sections
1. The upper part holds the name of the class.
2. The middle part contains the attributes of the class.
3. The bottom part gives the methods or operations the class can take or undertake.
23
Final Project
2.1.1 Relational Class diagram of server side
Fig 2.1 Relational Class Diagram of server side
24
Final Project
2.1.2 Relational Class diagram of Client side
Fig 2.2 Relational Class Diagram of client side
25
Final Project
2.1.3 Inheritance and Generalized Class diagram of server side

.
Fig 2.3 Inheritance and Generalized Class Diagram of server side
26
Final Project
2.1.4 Inheritance and Generalized Class diagram of client side
Fig 2.4 Inheritance and Generalized Class Diagram of server side
2.2 Use Cases

In software and systems engineering, a use case is a list of steps, typically defining
interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a
system, to achieve a goal. The actor can be a human, an external system, or time.
27
Final Project
2.2.1 Main System module Use Case Diagram
Fig 2.5 Use Case Diagaram
28
Final Project
2.2.2
Add Record Use case module For Administrator
Fig 2.6 Add Record Use case modules For Administrator
29
Final Project
2.2.3 Delete Record Use case module For Administrator
Fig 2.7 Delete Record Use case modules For Administrator
30
Final Project
2.2.4 Update Record Use case module For Administrator
Fig 2.8 Update Record Use case modules For Administrator
31
Final Project
2.2.5 View Record Use case module For Administrator
Fig 2.9 View Record Use case modules For Administrator
32
Final Project
2.2.6 Add Record Use case module For Operator
Fig 2.10 Add Record Use case modules For Operator
33
Final Project
2.2.7 Delete Record Use case module For Operator
Fig 2.11 Delete Record Use case modules For Operator
34
Final Project
2.2.8 Update Record Use case module For Operator
Fig 2.12 Update Record Use case modules For Operator
35
Final Project
2.2.9 View Record Use case module For Operator
Fig 2.13 View Record Use case modules For Operator
36
Final Project
2.3 Sequence Diagram
Fig 2.14 Sequence Diagram
37
Final Project
2.3.1 Log in
2.3.2 Manage Stock
2.3.3 Generate invoice:
38
Final Project
2.3.4 Generate stock report:
2.3.5 Generate Supplier Report:
39
Final Project
2.4 Activity Diagram
Fig 2.15: Activity Diagram
40
Final Project
Chapter#3
Coding and Snapshots
41
Final Project
3.1
Login Module
Fig 3.1 Login Module
3.1.1 Coding
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Data.SqlClient;
namespace AutoLub
{
42
Final Project
publicpartialclassLogin : AutoLub.Form1
{
public Login()
{
InitializeComponent();
}
publicstaticint log;
Connection cc = newConnection();
privatevoid Login_Load(object sender, EventArgs e)
{
Text = cc.Title() + "(Login Form)";
}
publicvoid login()
{
try
{
SqlConnection con = newSqlConnection(cc.ConnectDB());
con.Open();
string q="select * from login where username = '" + textBox1.Text + "' and password = '" +
textBox2.Text + "' and role = '"+comboBox1 .Text+"'";
SqlCommand cmd = newSqlCommand(q, con);
SqlDataReader c = cmd.ExecuteReader();
if (c.Read()==true)
{
if (comboBox1.Text == "Admin")
{
log = 1;
}
43
Final Project
else
if (comboBox1.Text == "Operator")
{
log = 2;
}
Menu shw = newMenu();
shw.Show();
this.Hide();
}
else
{
MessageBox.Show("Login Failed");
}
}
catch (Exception ee)
{
MessageBox.Show(ee.Message);
}
}
privatevoid button1_Click(object sender, EventArgs e)
{
login();
}
privatevoid textBox2_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.Enter)
{
login();
44
Final Project
}
}
}
}
3.2 Menu Module
Fig 3.2 Menu Module
3.2.1 Coding
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
45
Final Project
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Data.SqlClient;
using System.Net;
using System.Net.Sockets;
namespace AutoLub
{
publicpartialclassMenu : AutoLub.Form1
{
public Menu()
{
InitializeComponent();
}
Socket client_sock;
Socket sock;
byte[] buffer = newbyte[1024];
Connection cc = newConnection();
publicvoid display1()
{
DataTable table = newDataTable();
con.Open();
SqlCommand cmd = newSqlCommand("select * from server1", con);
table.Columns.Add("Sid", typeof(string));
table.Columns.Add("date", typeof(string));
table.Columns.Add("Cname", typeof(string));
table.Columns.Add("cnic", typeof(string));
table.Columns.Add("contact", typeof(string));
46
Final Project
table.Columns.Add("address", typeof(string));
table.Columns.Add("vehicle", typeof(string));
table.Columns.Add("Lid", typeof(string));
table.Columns.Add("ServiceType", typeof(string));
table.Columns.Add("Scharge", typeof(string));
table.Columns.Add("Amount", typeof(string));
table.Columns.Add("oldreading", typeof(string));
table.Columns.Add("newreading", typeof(string));
table.Columns.Add("shop", typeof(string));
while (c.Read() == true)
{
//string date = Convert.ToDateTime(dob.Text).ToShortDateString();
table.Rows.Add(c.GetValue(0).ToString(), c.GetValue(1).ToString(),
c.GetValue(2).ToString(), c.GetValue(3).ToString(), c.GetValue(4).ToString(),
c.GetValue(11).ToString(), c.GetValue(12).ToString(), c.GetValue(13).ToString());
}
dataGridView1.DataSource = table;
}
publicvoid display()
{
con.Open();
SqlCommand cmd = newSqlCommand("select * from sales1", con);
47
Final Project
while(c.Read()==true)
{
}
}
privatevoid ubricantItemToolStripMenuItem_Click(object sender, EventArgs e)

{
Items h = newItems();
h.Show();
}
privatevoid lubricantCategoryToolStripMenuItem_Click(object sender, EventArgs e)

{
48
Final Project
Category k = newCategory();
k.Show();
}
structitems
{
publicstring Lname;
publicstring category;
publicstring LubType;
publicstring Rate;
publicstring ratepliter;
publicstring qty;
publicstring description;
}
structsales_update
{
publicstring date;
publicstring cname;
publicstring cnic;
publicstring contact;
publicstring address;
publicstring vehicle;
publicint itemcode;
publicstring itemname;
publicstring price;
publicstring ServiceType;
publicstring Scharges;
publicstring Amount;
publicstring oldreading;
49
Final Project
publicstring newreading;
}
void end_rec(IAsyncResult ir)
{
char[] seps = { ',' };
sock.EndReceive(ir);
string rec_msg = System.Text.UnicodeEncoding.Unicode.GetString(buffer);
// Split the string into parts.
string[] parts = rec_msg.Split(seps);
switch (parts[0])
{
case"sales":
int a1 = Convert.ToInt16(parts[8]);
string queryuser = "INSERT INTO server1 VALUES ('" + parts[1] + "' ,'" + parts[2] + "' ,'" +
parts[3] + "' ,'" + parts[4] + "' ,'" + parts[5] + "' ,'" + parts[6] + "' ,'" + parts[7] + "' ,'" + a1 + "' ,'"
+ parts[9] + "' ,'" + parts[10] + "' ,'" + parts[11] + "' ,'" + parts[12] + "' ,'" + parts[13] + "','" +
parts[14] + "' )";
con.Open();
SqlCommand cmd = newSqlCommand(queryuser, con);
int a = cmd.ExecuteNonQuery();
if(a == 1)
{
string signal = "sucess" + "," + "no" + ",";
client_sock = newSocket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);
byte[] send_buffer23 = System.Text.UnicodeEncoding.Unicode.GetBytes(signal);
50
Final Project
client_sock.BeginSendTo(send_buffer23, 0,
send_buffer23.Length, SocketFlags.None, newIPEndPoint(IPAddress.Parse("127.0.0.1"), 6001),
newAsyncCallback(end_send), client_sock);
break;
}
if (a == 0)
{
string signal = "no" + "," + "no" + ",";
client_sock = newSocket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);
byte[] send_buffer23 = System.Text.UnicodeEncoding.Unicode.GetBytes(signal);
client_sock.BeginSendTo(send_buffer23, 0,
send_buffer23.Length, SocketFlags.None, newIPEndPoint(IPAddress.Parse("127.0.0.1"), 6001),
newAsyncCallback(end_send), client_sock);
break;
}
break;
case"sales1":
SqlConnection con1 = newSqlConnection(cc.ConnectDB());
string queryuser1 = "INSERT INTO server1 VALUES ('" + parts[1] + "' ,'" + parts[2] + "' ,'" +
parts[3] + "' ,'" + parts[4] + "' ,'" + parts[5] + "' ,'" + parts[6] + "' ,'" + parts[7] + "' ,'" + parts[8] +
"' ,'" + parts[9] + "' ,'" + parts[10] + "' ,'" + parts[11] + "' ,'" + parts[12] + "' ,'" + parts[13] + "','" +
parts[14] + "' )";
con1.Open();
SqlCommand cmd1 = newSqlCommand(queryuser1, con1);
cmd1.ExecuteNonQuery();
break;
}
sock.BeginReceive(buffer, 0, 1024, SocketFlags.None, newAsyncCallback(end_rec), sock);

51
Final Project
}
void end_send(IAsyncResult ir)
{
try
{
client_sock.EndSend(ir);
}
catch
{
}
}
privatevoid Menu_Load(object sender, EventArgs e)
{
sock = newSocket(AddressFamily.InterNetwork, SocketType.Dgram,
ProtocolType.Udp);
sock.Bind(newIPEndPoint(IPAddress.Any, 6000));
sock.BeginReceive(buffer, 0, 1024, SocketFlags.None, newAsyncCallback(end_rec),
sock);
if (Login.log == 1)
{
display1();
}
else
if (Login.log == 2)
{
reportsToolStripMenuItem1.Visible = false;
52
Final Project
categoryToolStripMenuItem.Visible = false;
manageItemsToolStripMenuItem.Visible = false;
sendPromotionsToolStripMenuItem1.Visible = false;
toolsToolStripMenuItem.Visible = false;
supplierToolStripMenuItem.Visible = false;
sendPromotionsToolStripMenuItem1.Visible = false;
toolsToolStripMenuItem1.Visible = false;
supplierToolStripMenuItem1.Visible = false;
display();
}
Text = cc.Title() + "(Main Menu)";
}
privatevoid textBox1_TextChanged(object sender, EventArgs e)

{
con.Open();
SqlCommand cmd = newSqlCommand(" select * from sales1 where shop like '%" +
textBox1.Text + "%'", con);
53
Final Project
while (c.Read() == true)
{
//string date = Convert.ToDateTime(dob.Text).ToShortDateString();
}
}
privatevoid categoryToolStripMenuItem_Click(object sender, EventArgs e)

{
Category obj = newCategory();
obj.Show();
}
privatevoid manageItemsToolStripMenuItem_Click(object sender, EventArgs e)

{
Items obj = newItems();
obj.Show();
}
54
Final Project
privatevoid customerToolStripMenuItem_Click(object sender, EventArgs e)

{
customer obj = newcustomer();
obj.Show();
}
privatevoid employeesToolStripMenuItem_Click(object sender, EventArgs e)

{
Employee obj = newEmployee();
obj.Show();
}
privatevoid salesToolStripMenuItem1_Click(object sender, EventArgs e)

{
Sales obj = newSales();
obj.Show();
}
privatevoid sendPromotionsToolStripMenuItem1_Click(object sender, EventArgs e)

{
Promotions obj = newPromotions();
obj.Show();
}
privatevoid feedbackToolStripMenuItem1_Click(object sender, EventArgs e)

{
Feedback obj = newFeedback();
obj.Show();
}
55
Final Project
privatevoid userWizardToolStripMenuItem1_Click(object sender, EventArgs e)

{
UserWizard obj = newUserWizard();
obj.Show();
}
privatevoid reportsToolStripMenuItem1_Click(object sender, EventArgs e)

{
privatevoid toolsToolStripMenuItem1_Click(object sender, EventArgs e)

{
privatevoid supplierToolStripMenuItem1_Click(object sender, EventArgs e)

{
Supplier obj = newSupplier();
obj.Show();
}
56
Final Project
3.3 Category Module
Fig 3.3 Category Module
3.4
Item Details Module
Fig 3.4 Item Details Module
57
Final Project
3.5 Customer Module
Fig 3.5 Customer Module
3.6 Employee Module
Fig 3.6 Employee Module
58
Final Project
3.7 Sale Module
Fig 3.7 Sale Module
3.8 Supplier Module
Fig 3.8 Supplier Module
59
Final Project
3.9 Feedback Module
Fig 3.9 Feedback Module
3.10 Send Promotion Module
Fig 3.10 Send Promotion Module
60
Final Project
3.11 User Wizard
Fig 3.11 User Wizard Module
61
Final Project
Chapter#4
Testing
62
Final Project
4.1 Introduction
In the Computer Sciences context, testing is regarded as a quality assurance activity. Its aim
is to verify/ ensure compliance of the software component under test with stated requirements.
There are two main categories of testing: static and dynamic. Static testing techniques include
desk checking, walkthroughs, inspections, and compiling. Dynamic testing comprises both white
and black box techniques.
4.2 Unit Testing

Unit Testing is carried out to check developed software independently. In this step each
module in developed system is tested one by one to find errors and to check its proper
functioning.
The main advantage of this system is that we can check each module independently for any
errors and correct these errors at first time.
4.3 Integrated Testing

In this step of testing, we test all module of the developed system simultaneously to check
whether all modules are performing correctly while interacting with each other as well as
required form launched when we call it.
We perform integrated testing for our system and found that all forms or block which are
interlinked to each other are working correctly and required form call at any press.
4.4 Subsystem and System Testing

In this step of testing we take multiple modules and start testing that whether they perform
correct function while interacting to each other.
.Two kinds of system testing are done:
Functional Testing
The requirements from Requirement analysis document were tested to find functional
requirements fulfillment without errors.
63
Final Project
Performance Testing
Performance Testing was performed to check the non-functional requirements. All the
non-functional requirements of the system were checked and all the errors and problems
were recorded.
4.5 Black Box and White Box Testing

White-box testing also called glass-box testing that uses the control structure of the
procedural design to derive test cases. Using white-box testing methods, the software engineer
can derive test cases that grantee all independent paths within a module have been exercised at
least once, execute all loops at their boundaries bounds, and exercise internal data structure to
ensure their validity.
Black-box testing enables the software engineer to derive sets of input conditions that fully
exercise all functional requirements for a program. It is a complementary approach that is likely
to uncover a different class of errors than white-box methods.
Black-box testing attempt to find errors in following categories;
1. Incorrect or missing functions.
2. Interface errors.
3. Errors in data structures or external data base access.
4. Behavior or performance errors.
5. Initialization and termination errors.
4.6 Test cases with black box tests

A test case is done with a set of input data and expected result that exercises a component
with the purpose of causing failures and detecting faults. Following are some of the test cases to
test the application:
64
Final Project
4.6.1 Test Case 1: Login

Identification
Identification of this test case is 1.
Test items
Accessing login information of AutoLube System.
Input specification
Enter user name and Password.
Output specification
Information regarding user name, password etc. is successfully accessed from
database.
Environmental needs
Integrated development environment of visual studio .Net 2012 (C#)
Table 4.1 Test Case 1: Login
65
Final Project
4.6.2 Test Case 2: Category

Identification
Test items
Enumerating Category information of AutoLube System
Input specification
In Menu strip click on Category button.
Submit buttons are checked one by one Testing is successful. Data is successfully
add, delete and updated in database.
Environmental needs
Integrated development environment of visual studio .Net(C#)
4.6.3 Test Case 3: Manage Items

Identification
Test items
Enumerating Manage Items information of AutoLube System.
Input specification
Click on Manage Items button in Menu strip.
Add buttons are checked. Testing is successful. Data is successfully added, deleted
and updated in database.
Environmental needs
66
Final Project
4.6.4 Test Case 4: Customer

Identification
Test items
Enumerating Customer information of AutoLube System.
Input specification
Click on Customer in context Menu Strip.
Add, delete and Update buttons are checked one by one Testing is successful. Data
is successfully added, deleted and updated in database.
Environmental needs
4.6.5 Test Case 5: Sales

Identification
Test items
Enumerating Sales information of AutoLube System.
Input specification
Click on Sales button in Menu Strip.
Add, Delete and Update buttons are checked one by one Testing is successful. Data
Environmental needs
Integrated development environment of visual studio.Net 2012
67
Final Project
4.6.6 Test Case 6: Reports

Identification
Test items
Enumerating Reports information of AutoLube System.
Input specification
Click on Reports button in context menu strip.
When Testing is successful it generates Reports of Stock, Customers, Sales and
Salary.
Environmental needs
4.6.7 Test Case 7: Send Promotions

Identification
Test items
Enumerating Promotions of Employees in AutoLube System.
Input specification
Click on Send Promotions in Menu Strip.
It sends Promotions to all Employees and send data to Customers.
Environmental needs
68
Final Project
4.6.8 Test Case 8: Tools

Identification
Test items
Enumerating User Wizard information of AutoLube System.
Input specification
Click on Tools in context Menu Strip.
Add, Delete and Update buttons are checked one by one Testing is successful. Data
Environmental needs
4.6.9 Test Case 9: Feedback

Identification
Test items
Enumerating Feedback information of AutoLube System.
Input specification
Click on Feedback in Menu Strip.
Add, Delete and Update buttons are checked one by one. Testing is successful. Data
69
Final Project
Environmental needs
4.6.10 Test Case 10: Employee

Identification
Test items
Enumerating Employees information in AutoLube System.
Input specification
Click on Employee in Menu Strip.
Add, Delete and Update buttons are checked one by one. Testing is successful. Data
Environmental needs
70
Final Project
Bibliography
1. Solving University Course Timetabling Problems Using Constriction Particle Swarm

Optimization with Local Search. Ruey-Maw Chen, Hsiao Fang Shih. April 19, 2013,
Algorithms. 1999-4893.
2. Software Engineering. Jibitesh Mishra, Ashok Mohanty. s.l. : Pearson Education India,
2011. 8131765350.
3. Jeffrey A. Hoffer, V. Ramesh, Heikki Topi.Modern Database Management. 10. s.l. :
Prentice Hall, 2010. 0136088392.
4. GradyBooch, James Rumbaugh, Ivar Jacobson.The Unified Modeling Language User
Guide. 1st. s.l. : Addison Wesley, 1998. 0-201-57168-4.
5. Binder, Robert V.Testing Object-Oriented Systems: Objects, Patterns, and Tools. s.l. :
Addison-Wesley Professional, 1999. 0-201-80938-9.
6. Standard glossary of terms used in Software Testing. Veenendaal, Erik van. 2013.
71

Final Documentation For Lub

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Final Documentation For Lub

Încărcat de

Drepturi de autor:

Formate disponibile

Final Project

Distributed Lubricant Sale Point System

Feasibility Report ................................................................................................... 8

1.2.2 Technical feasibility ................................................................................................... 9

Distributed Lubricant Sale Point System

1.12.3 Environment friendly: ............................................................................................. 17

User Interface & Database Design ......................................................................................... 21

2.1 System Design ....................................................................................................................... 22

Distributed Lubricant Sale Point System

2.3.2 Manage Stock ............................................................................................................ 38

Distributed Lubricant Sale Point System

4.6.5 Test Case 5: Sales ............................................................................................... 67

Distributed Lubricant Sale Point System

Distributed Lubricant Sale Point System

Fig 3.11 User Wizard Module..61

Distributed Lubricant Sale Point System

Distributed Lubricant Sale Point System

1.2 Existing system and Fesibility Report

Distributed Lubricant Sale Point System

1.2.2 Technical feasibility

1.2.3 Economical feasibility

.net frame work

1000 Per year

Distributed Lubricant Sale Point System

1.2.4 Legal feasibility

1.2.5 Operational feasibility

The proposed system will meet increasing future needs.

It will provide friendly environment to user to maintain sale records.

Proposed system will provide a user friendly interface for interaction.

Distributed Lubricant Sale Point System

1.2.6 Schedule feasibility

1.2.7 Specification feasibility

Distributed Lubricant Sale Point System

1.2.7 Informational feasibility

1.2.8 Motivational feasibility

1.2.9 Is project Feasible or not?

1.3 Problem Statement

Difficult to maintain different branches records.

No proper way to manage the staff salary records.

No proper way to the stock records.

Distributed Lubricant Sale Point System

1.4 Objective & Goals

1.5 Project scope

Distributed Lubricant Sale Point System

1.6 Proposed System

1.7 User Classes

Distributed Lubricant Sale Point System

1.8 Operating Environment

Pentium 3 or Higher Processor Minimum Speed 2.4GHZ.

Hard disk of 10GB capacity or more.

Minimum 1GB RAM or higher.

Standard output display with color resolution scheme 1280/768.

1.8.2 Software Interface

Microsoft Windows 7, 8 or Service Pack 3.

SQL 2008 should be installed.

Visual Studio 2012.

1.9 Design and Implementation Constraints

A general knowledge of basic computer skills and of basic working of Distributed

Distributed Lubricant Sale Point System

1.10 User Documentation

SRS in MS- Word.

Microsoft Visual Studio 2012 for Application Creation.

The databases will be created in the Microsoft SQL server 2008.