ABSTRACT:
This project implements the gas booking process in online. It’s an application that which maintains all the details of the customer who have registered the details during the booking process. Here the records of the customer are maintained. The current system makes use of notebooks or ledgers to maintain the details. All the records are entered and accessed manually. While maintaining the details in ledgers it becomes very difficult to view the records. Moreover it is very much essential to be aware of all records. Now in this application MS ACCESS & C are used to store & retrieve the records. Information recorded automatically updated into the database accordingly to the data needs. The objectives of the proposed system are to have a detailed review of the customers at present. The input to the application is the details of the customers based on the booking details. The output is the details that are collected from the application and are given out under specific conditions. REQUIREMENT ANALYSIS:
It results in the specification of software’s operational characteristics, indicates software’s interface with other system elements and establishes constraints that
software must meet. The aim of analysis is to understand the problem with a view to eliminate any deficiencies in the requirement specification such as incompleteness, Inconsistencies, etc. The model which we are trying to build may be or may not be ready.
OVERALL OBJECTIVES AND PHILOSOPHY:
USER REQUIREMENT:
• Details of the their booking id• Details of agency
• Mode of payment
• Date of booking
DEVELOPER REQUIREMENT:
• Details of the customers who booked gas• The address of the place to be gas delivered
• Contact number of the customer
• Date of booking
• Software and hardware requirements as mentioned above.
SOFTWARE REQUIREMENT SYSTEM (SRS):
FUNCTIONAL REQUIREMENTS:
• Gas delivery
• Date of booking
• Delivery time
The software requirements of the application are:
• FRONTEND: VC++
• BACKEND: MSACCESS
• DRIVER: ODBC
The hardware requirements of the application are:
• INTEL PENTIUM 3
• MINIMUM 128 RAM
Goal of implementation:
The primary goal of this application is to maintain a perfect record of the auctioneers who have auctioned the properties at different places. This is achieved by the above mentioned requirements.DESIGN:
Software design deals with transforming the customer requirements, as described in the SRS document, into a form (a set of documents) that is suitable for implementation in a programming language. A good software design is seldom arrived by using a single step procedure but rather through several iterations through a series of steps. Design activities can be broadly classified into two important parts: • Preliminary (or high-level) design and
• Detailed design.
The aim of design is to produce a model that will provide a seamless transition to the coding phase, i.e. once the requirements are analyzed and found to be satisfactory, a design model is created which can be easily implemented.
Characteristics of a good software design:
The characteristics are listed below:
• Correctness: This application has got a perfect design that which correctly implement all the functionalities identified in the SRS document.
• Understandability: our application is easily understandable.
• Efficiency: our application is highly efficient.
• Maintainability: It is easily amenable to change.
Data Flow Diagram (Level 0)
Component Description:
Entity Relationship Diagram:
Component Description:
TESTING:
Testing a program consists of providing the program with a set of test inputs (or test cases) and observing if the program behaves as expected. If the program fails to behave as expected, then the conditions under which failure occurs are noted for later debugging and correction. Unit testing :
Unit testing is undertaken after a module has been coded and successfully reviewed. Unit testing (or module testing) is the testing of different units (or modules) of a system in isolation. In order to test a single module, a complete environment is needed to provide all that is necessary for execution of the module. That is, besides the module under test itself, the following steps are needed in order to be able to test the module:
• The procedures belonging to other modules that the module under test calls.
• Non local data structures that the module accesses.
• A procedure to call the functions of the module under test with appropriate parameters
System testing:
System tests are designed to validate a fully developed system to assure that it meets its requirements.
There are essentially three main kinds of system testing:
• Alpha Testing. Alpha testing refers to the system testing carried out by the test team within the developing organization.
• Beta testing. Beta testing is the system testing performed by a select group of friendly customers.
• Acceptance Testing. Acceptance testing is the system testing performed by the customer to determine whether he should accept the delivery of the system
SOURCE CODE:
#include<windows.h>
#include<sqlext.h>
#include<sql.h>
#include<stdio.h>
#define TEXT_LEN 50
int main()
{
int choice;
SQLINTEGER consumerid,contactno;
SQLCHAR customername[TEXT_LEN], address1[TEXT_LEN], address2[TEXT_LEN],emailaddress[TEXT_LEN],dateofbooking[TEXT_LEN];
HENV hENV=NULL;
HDBC hDBC=NULL;
HSTMT hStmt=NULL;
UCHAR szSqlstr[]="insert into table1(customername,emailaddress,consumerid, address1,address2,contactno,dateofbooking)values(?,?,?,?,?,?,?)";
UCHAR szSqlstr1[]="delete * from table1 where consumerid = ?";
UCHAR szSqlstr2[]="select * from table1 where consumerid = ?";
UCHAR szDSN[SQL_MAX_DSN_LENGTH]="gas";
UCHAR *szUID=NULL;
UCHAR *szpasswd=NULL;
UCHAR szModel1[128];
UCHAR szModel2[128];
UCHAR szModel3[128];
UCHAR szModel4[128];
UCHAR szModel5[128];
UCHAR szModel6[128];
UCHAR szModel7[128];
SDWORD cbModel1;
SDWORD cbModel2;
SDWORD cbModel3;
SDWORD cbModel4;
SDWORD cbModel5;
SDWORD cbModel6;
SDWORD cbModel7;
SDWORD cbtest=SQL_NTS;
RETCODE retcode;
A:
printf("\n\n\t\tONLINE GAS BOOKING SYSTEM ");
printf("\n______________________________________________");
printf("\n1.gasBooking\t2.Cancelcustrrecord\t3.Displaybookingdetails\t4.Exit");
printf("\n______________________________________________");
printf("\n\nEnter your choice:\t");
scanf("%d",&choice);
printf("\n______________________________________________");
switch(choice)
{
case 1:
printf("\n-----------------------------------------");
printf("\nBooking Section");
printf("\n-----------------------------------------");
printf("\nEnter the Customer name:\t");
scanf("%s",&customername);
printf("\nEnter the email address:\t");
scanf("%s",&emailaddress);
printf("\nConsumer ID:\t");
scanf("%d",&consumerid);
printf("\nAddress1:\t");
scanf("%s",&address1);
printf("\nAddress2:\t");
scanf("%s",&address2);
printf("\ncontactno :\t");
scanf("%d",&contactno);
printf("\n dateofbooking:\t");
scanf("%s",&dateofbooking);
printf("\n-----------------------------------------");
SQLAllocEnv(&hENV);
SQLAllocConnect(hENV,&hDBC);
retcode=SQLConnect(hDBC,szDSN,SQL_NTS,szUID,SQL_NTS,
szpasswd,SQL_NTS);
if(retcode==SQL_SUCCESS||retcode==SQL_SUCCESS_WITH_INFO)
{
retcode=SQLAllocStmt(hDBC,&hStmt);
retcode=SQLPrepare(hStmt,szSqlstr,sizeof(szSqlstr));
SQLBindParameter (hStmt, 1,SQL_PARAM_INPUT,SQL_C_CHAR,
SQL_CHAR,TEXT_LEN,0,customername,0,&cbtest);
SQLBindParameter(hStmt,2,SQL_PARAM_INPUT,SQL_C_CHAR,
SQL_CHAR,TEXT_LEN,0,emailaddress,0,&cbtest);
SQLBindParameter(hStmt,3,SQL_PARAM_INPUT,SQL_C_LONG,
SQL_INTEGER,1,0,&consumerid,0,&consumerid);
SQLBindParameter(hStmt,4,SQL_PARAM_INPUT,SQL_C_CHAR,
SQL_CHAR,TEXT_LEN,0,address1,0,&cbtest);
SQLBindParameter(hStmt,5,SQL_PARAM_INPUT,SQL_C_CHAR,
SQL_CHAR,TEXT_LEN,0,address2,0,&cbtest);
SQLBindParameter(hStmt,6,SQL_PARAM_INPUT,SQL_C_LONG,
SQL_INTEGER,1,0,&contactno,0,&contactno);
SQLBindParameter(hStmt,7,SQL_PARAM_INPUT,SQL_C_CHAR,
SQL_CHAR,TEXT_LEN,0,dateofbooking,0,&cbtest);
retcode=SQLExecute(hStmt);
printf("\n\n Gas is Booked ");
}
break;
case 2:
printf("\n===========================================");
printf("\n cancellation section ");
printf("\n===========================================");
SQLAllocEnv(&hENV);
SQLAllocConnect(hENV,&hDBC);
retcode=SQLConnect(hDBC,szDSN,SQL_NTS,szUID,SQL_NTS,
szpasswd,SQL_NTS);
if(retcode==SQL_SUCCESS||retcode==SQL_SUCCESS_WITH_INFO)
{
retcode=SQLAllocStmt(hDBC,&hStmt);
retcode=SQLPrepare(hStmt,szSqlstr1,sizeof(szSqlstr1));
SQLBindParameter(hStmt,1,SQL_PARAM_INPUT,SQL_C_LONG,
SQL_INTEGER,1,0,&consumerid,0,&consumerid);
printf("\n Enter the consumer ID:\t");
scanf("%d",&consumerid);
retcode=SQLExecute(hStmt);
printf("\n\n Customer detail is cancelled");
}
break;
case 3:
printf("\n\n*****************************************");
printf("\n Display Gas Booked ");
printf("\n\n*****************************************");
SQLAllocEnv(&hENV);
SQLAllocConnect(hENV,&hDBC);
retcode=SQLConnect(hDBC,szDSN,SQL_NTS,szUID,SQL_NTS,
szpasswd,SQL_NTS);
if(retcode==SQL_SUCCESS||retcode==SQL_SUCCESS_WITH_INFO)
{
retcode=SQLAllocStmt(hDBC,&hStmt);
retcode=SQLPrepare(hStmt,szSqlstr2,sizeof(szSqlstr2));
SQLBindParameter(hStmt,1,SQL_PARAM_INPUT,SQL_C_LONG,
SQL_INTEGER,1,0,&consumerid,0,&consumerid);
printf("\n Enter the Consumer Id:\t");
scanf("%d",&consumerid);
retcode=SQLExecute(hStmt);
SQLBindCol(hStmt,1,SQL_C_CHAR,szModel1,sizeof(szModel1),&cbModel1);
SQLBindCol(hStmt,2,SQL_C_CHAR,szModel2,sizeof(szModel2),&cbModel2);
SQLBindCol(hStmt,3,SQL_C_CHAR,szModel3,sizeof(szModel3),&cbModel3);
SQLBindCol(hStmt,4,SQL_C_CHAR,szModel4,sizeof(szModel4),&cbModel4);
SQLBindCol(hStmt,5,SQL_C_CHAR,szModel5,sizeof(szModel5),&cbModel5);
SQLBindCol(hStmt,6,SQL_C_CHAR,szModel6,sizeof(szModel6),&cbModel6);
SQLBindCol(hStmt,7,SQL_C_CHAR,szModel7,sizeof(szModel7),&cbModel7);
retcode=SQLFetch(hStmt);
while(retcode==SQL_SUCCESS||retcode==SQL_SUCCESS_WITH_INFO)
{
printf("\nCustomer Name: %s\temailaddr:%s\tCustomer ID:%s\n",szModel1,szModel2,szModel3);
printf("\naddr1: %s\taddr2: %s\n\ncontactno:%s\tdate:%s\n",szModel4,szModel5,szModel6,szModel7);
retcode=SQLFetch(hStmt);
}
}
break;
case 4:
exit(0);
break;
default:
printf("\n\n***********Wrong choice***********\n\n");
break;
}
flushall();
goto A;
return 0;
}
OUTPUT:
GAS BOOKING:
DISPLAY:
CANCELLATION:
DISPLAY:
CONCLUSION:
Thus our application- online gas booking is successfully automated with the mentioned software and hardware requirements. The records that are entered in are automatically updated in the database with the ODBC driver. The above mentioned testing techniques are also performed and our application is finally deployed to our customers. This automated system has the advantage of maintaining the records properly without any manual stress. Hence it becomes easier for the user to automate the property auctioned. The maintenance of our system wholly depends on the customer’s risk.
1 comments:
Write commentscan u send the database
ReplyEmoticonEmoticon