Final Documentation for lub

Final Project Distributed Lubricant Sale Point System

1

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


2

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


3

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


4

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


5

List of Figures:

Fig 1.1: Itrative Waterfall Model………………………………………………………………………20

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 side……………………………………26

Fig 2.4 Inheritance and Generalized Class Diagram of server side……………………………………27

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 Administrator……………………………………………32

Fig 2.10 Add Record Use case modules For Operator…………………………………………………33

Fig 2.11 Delete Record Use case modules For Operator………………………………………………34

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 Module………………………………………………………………………………57

Fig 3.4 Item Details Module……………………………………………………………………………57

Fig 3.5 Customer Module……………………………………………………………………………...58

Fig 3.6 Employee Module……………………………………………………………………………..58

Fig 3.7 Sale Module……………………………………………………………………………………59

Fig 3.8 Supplier Module……………………………………………………………………………….59

Fig 3.9 Feedback Module………………………………………………………………………………60

Fig 3.10 Send Promotion Module………………………………………………………………………60


6

Fig 3.11 User Wizard Module………………………………………………………………………..61

List of Tables :

Table 1.1: Economical feasibility……………………………………………………………………...09

Table 1.2: Schedule feasibility………………………………………………………………………...11


7

Chapter# 1

Requirements Analysis & Specification


8

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?


9

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


10

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.


11

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 1 2 3 4 5 6 7 8 9 10 11

A:Rizwan Tabassum

B:Rizwan Amjad

C:Sajjad Amhed

D:Rizwan Tabassum

E:Naveed Saeed

F:Naveed-

Saeed/Sajjad Amhed

G:Naveed Saeed

H:Naveed-

Saeed/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.


12

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.


13

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 employee’s 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.


14

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.

St a f f s t ha t wi l l be u s e the sale point system in different shops and their sales

record admin can see.


15

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.


16

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.


17

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 Employee’s.

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.


18

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


19

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.


20

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.


21

Chapter#2

User Interface & Database Design


22

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.


23

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 system’s 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.


24

2.1.1 Relational Class diagram of server side

Fig 2.1 Relational Class Diagram of server side


25

2.1.2 Relational Class diagram of Client side

Fig 2.2 Relational Class Diagram of client side


26

2.1.3 Inheritance and Generalized Class diagram of server side .

Fig 2.3 Inheritance and Generalized Class Diagram of server side


27

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.

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Systems_engineering

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Actor_(UML)


28

2.2.1 Main System module Use Case Diagram

Fig 2.5 Use Case Diagaram


29

2.2.2 Add Record Use case module For Administrator

Fig 2.6 Add Record Use case modules For Administrator


30

2.2.3 Delete Record Use case module For Administrator

Fig 2.7 Delete Record Use case modules For Administrator


31

2.2.4 Update Record Use case module For Administrator

Fig 2.8 Update Record Use case modules For Administrator


32

2.2.5 View Record Use case module For Administrator

Fig 2.9 View Record Use case modules For Administrator


33

2.2.6 Add Record Use case module For Operator

Fig 2.10 Add Record Use case modules For Operator


34

2.2.7 Delete Record Use case module For Operator

Fig 2.11 Delete Record Use case modules For Operator


35

2.2.8 Update Record Use case module For Operator

Fig 2.12 Update Record Use case modules For Operator


36

2.2.9 View Record Use case module For Operator

Fig 2.13 View Record Use case modules For Operator


37

2.3 Sequence Diagram

Fig 2.14 Sequence Diagram


38

2.3.1 Log in

2.3.2 Manage Stock

2.3.3 Generate invoice:


39

2.3.4 Generate stock report:

2.3.5 Generate Supplier Report:


40

2.4 Activity Diagram

Fig 2.15: Activity Diagram


41

Chapter#3

Coding and Snapshots


42

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

{


43

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;

}


44

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();


45

}

}

}

}

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;


46

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));


47

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);






48












while(c.Read()==true)

{






}


}

privatevoid ubricantItemToolStripMenuItem_Click(object sender, EventArgs e)

{

Items h = newItems();

h.Show();

}

privatevoid lubricantCategoryToolStripMenuItem_Click(object sender, EventArgs e)

{


49

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;


50

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);


51

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);


52

}

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;


53

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);











54







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();

}


55

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();

}


56

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();

}


57

3.3 Category Module

Fig 3.3 Category Module

3.4 Item Details Module

Fig 3.4 Item Details Module


58

3.5 Customer Module

Fig 3.5 Customer Module

3.6 Employee Module

Fig 3.6 Employee Module


59

3.7 Sale Module

Fig 3.7 Sale Module

3.8 Supplier Module

Fig 3.8 Supplier Module


60

3.9 Feedback Module

Fig 3.9 Feedback Module

3.10 Send Promotion Module

Fig 3.10 Send Promotion Module


61

3.11 User Wizard

Fig 3.11 User Wizard Module


62

Chapter#4

Testing


63

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.


64

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:


65

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”


66

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



67

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


68

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


69


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



70

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



71

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.

Date post:	20-Feb-2016
Category:	Documents
Upload:	nav
View:	237 times
Download:	3 times

Final Documentation for lub

Documents