car centralize

CENTRALIZE SELLS, SERVICE &DEALS FOR AUTOMOBILE INDUSTRIES

S.P.B PATEL ENGINEERING COLLEGE,MEHSANA

Centralize Sells,Service & Deals For Automobile Industries

A PROJECT REPORT Submitted by

Bhavik panchal

Niket Anand

Dharmesh Solanki

In fulfillment for the award of the degree

of

BACHELOR OF ENGINEERING

in

Department Of Computer Engineering

S.P.B PATEL ENGINEERING COLLEGE, MEHSANA

Gujarat Technological University, Ahmedabad

December, 2012



Saffrony Institute Of Technology

Computer Engineering

2012

CERTIFICATE

Date:

This is to certify that the dissertation entitled ―CENTRALIZE SALES,SERVICE & DEALS

FOR AUTOMOBILE INDUSTRIES‖ has been carried out by Bhavik

Panchal(090390107046),Nike Anand(090390107061),Dharmesh Solanki(090390107021) under

my guidance in fulfilment of the degree of Bachelor of Engineering in COMPUTER

ENGINEERING(7th

Semester) of Gujarat Technological University, Ahmedabad during the

academic year 2012-2013.

Guides: Head of Department

Mr. Parimal Patel

Assistant Professor.

Computer Department



Acknowledgement

The satisfaction that accompanies that the successful completion of any task would be

incomplete without the mention of people whose ceaseless cooperation made it possible, whose

constant guidance and encouragement crown all efforts with success.

Hereby, my first and foremost thanking goes to Mr. Parimal Patel for the knowledge and

guidance provided to me on the project work. I gratefully thank them for extending to me there

invaluable time and resources.

We would also like to thank Mr.Dhaval Gohil Head of Dept. I.T., to whom I own pleasurable

debt for her splendid support, inspiration and thought production.

We also thank our colleagues who have helped in successful completion of the project.

Bhavik Panchal(09039010

Niket Anand(090390107061)

Dharmesh Solanki(090390107021)



ABSTRACT

CENTRALIZE OF SELLS SERVICE AND DEALS FOR AUTOMOBILE INDUSTRIES to make

the management of the Cars and its customer in an efficient way to lessen the effort.

Car Sells Service and Deals are a method of selling new, and most often, used vehicles based

on auction system. car sales can be found in most nations, but are often unknown to most people.

A car dealership is a business that sells new or used cars at the retail level, based on a

dealership contract with an sales subsidiary. It employs automobile sells people to do the selling.

It may also provide maintenance services for cars, thus employing Automotive Technicians ,

stock and sell spare automobile parts, and process warranty claims.

Users of this project can login with their user name and password can search different car

models, price, manufacture date, engine mileage, petrol or diesel car, etc.

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

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

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

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

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

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

http://en.wikipedia.org/wiki/Service_%28motor_vehicle%29

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

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



LIST OF TABLS

Table No

Table Description

Page No

Table 1

CAR INFO

-

Table 2

FEEDBACK

-

Table 3

CAR SCHEME

-

Table 4

BUYER INFO

-

Table 5

SELLER INFO

-

Table 6

ADMIN INFO

-



LIST OF FIGURES

Sr. No. Figure Name & Description Page No.

1. Activity Diagram 20

- A type of static structure diagram that describes the

structure of a system by showing the system's classes,

their attributes, operations (or methods), and the

relationships among the classes.

- Admin

- Seller

- Buyer

2. E-R Diagram 22

- An abstract and conceptual representation of data that

represents the relationship between entities.

3. Structure Diagram 24

- Describes the behavior of systems about its states on

particular events

4. Use-Case Diagram

26

- To present a graphical overview of the functionality

provided by a system in terms of actors



- Admin

- Seller

- Buyer

5. Data Flow Diagram 28

- A graphical representation of the "flow" of data through

an information system, modelling its process aspects.

n Context Level 28

n First Level 29

n Second Level 30

n Third Level



TABLE OF CONTENTS

Acknowledgement………………………………………………………………

Abstract…………………………………………………………………………

List of Tables

List of Figures

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 Objective Of Work

1.2 Scope Of Work

1.3 Technology Used

1.3.1 Hardware And Software Requirement

1.3.2 Technology Description

1.3.2.1 Html

1.3.2.2 Java Script

1.3.2.3 Java Technology

1.3.2.4 Java Database & JDBC

1.3.2.6 SQL



1.3.2.7 Servlet

2. Project Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.1 Milestones And Deliverables

2.2 Risk Management

2.2.1 Risk Identification

2.2.2 Risk Analysis

2.2.3 Risk Planning

2.2.4 Risk Monitoring

3. System Analysis And Requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Requirement Of The System

3.2 Feasibility Study

3.3Features Of The System

3.4 Main Modules Of The System

4. System Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Activity Diagram

4.1.1 Activity Diagram For Admin

4.1.2 Activity Diagram For Seller

4.1.3 Activity Diagram For Buyer



4.2 E-R Diagram

4.3 Structure Diagram

4.4 Use Case Diagram

4.1.1 Use Case Diagram For Admin

4.1.2 Use Case Diagram For Seller

4.1.3 Use Case Diagram For Buyer

4.5 Data Flow Diagram

4.5.1 Zero Level

4.5.2 First Level

4.5.3 Second Level

4.5.4 Third Level

4.6 Sequence Diagram

4.6 Data Dictionary

5. Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . 36

6. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 38

7. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39



1.INTRODUCTION



1.1 OBJECTIVE OF WORK

1.2 SCOPE OF WORK



1.3 TECHNOLOGY USED

1.3.1 HARDWARE AND SOFTWARE REQUIREMENTS

SOFTWARE REQUIREMENTS

Front End: Java

Ø Create interactive and dynamic web pages.

Ø Open source software (OSS)

.

Ø CSS

Ø Apache Server Back End: SQL SERVER 2005

Ø An open source relational database management system.

Ø Google API Operating System :

Ø WINDOWS 2000/07/XP/Vista

Browser :

Ø Internet Explorer 5.5 OR

Above Ø Mozilla Firefox 3.6 OR



Above Ø Google Chrome

Ø Opera Browser

Ø Apple Safari

Hardware Requirement :

Ø Processor: Pentium III or Above

Ø Clock speed: 800 MHZ

Ø System bus: 32 BIT

Ø Ram: 256MB or more

Ø HDD: 40GB

Ø Monitor: SVGA COLOR

Ø Keyboard: 101 KEYS

Ø Modem: 56 KBPS/ADSL Broadband

Ø Mouse: PS2/ Serial



1.3.2 TECHNOLOGY DESCRIPTION

The proposal has to be described in a detailed form to get an overview and an

understanding of the functionalities of the technical approach. This provides the technical

description of the characteristics of a proposal.

1.3.2.1 HTML

HTML, an initialize of Hypertext Markup Language, is the predominant markup

language for web pages. It provides a means to describe the structure of text-based

information in a document — by denoting certain text as headings, paragraphs, lists, and

soon — and to supplement that text with interactive forms, embedded images, and other

objects.

1.3.2.2 JAVA SCRIPT

JavaScript is a script-based programming language that was developed by Netscape

Communication Corporation. JavaScript was originally called Live Script and renamed as

JavaScript to indicate its relationship with Java. JavaScript supports the development of

both client and server components of Web-based applications. On the client side, it can

be used to write programs that are executed by a Web browser within the context of a

Web page. On the server side, it can be used to write [11] Web server programs that can

process information submitted by a Web browser and then update the browser‘s display

accordingly.



1.3.2.3 JAVA TECHNOLOGY

Initially the language was called as ―oak‖ but it was renamed as ―Java‖ in 1995. The

primary motivation of this language was the need for a platform-independent (i.e.,

architecture neutral) language that could be used to create software to be embedded in

various consumer electronic devices:

Java is a programmer‘s language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment, Java gives the

programmer, full control.

Finally, Java is to Internet programming where C was to system programming.

1.3.2.4 JAVA DATABASE CONECTIVITY

JDBC is a Java API for executing SQL statements. (As a point of interest, JDBC is a

trademarked name and is not an acronym; nevertheless, JDBC is often thought of as

standing for Java Database Connectivity. It consists of a set of classes and interfaces

written in the Java programming language. JDBC provides a standard API for

tool/database developers and makes it possible to write database applications using a pure

Java API. Simply put, JDBC makes it possible to do three things:

Establish a connection with a database.

Send SQL statements.

Process the results.



1.3.2.5 JAVA DATABASE CONECTIVITY

The JDBC provides database-independent connectivity between the J2EE platform

and a wide range of tabular data sources. JDBC technology allows an Application

Component Provider to:

Perform connection and authentication to a database server.

Manager transactions.

Move SQL statements to a database engine for preprocessing and execution.

Execute stored procedures.

Inspect and modify the results from Select statements

1.3.2.6 SQL

Structured Query Language (SQL) is the language used to manipulate relational

databases. SQL is tied very closely with the relational model. In the relational model,

data is stored in structures called relations or tables. SQL statements are issued for the

purpose of:

Data definition: Defining tables and structures in the database (DDL used to create,

alter and drop schema objects such as tables and indexes).

Data manipulation: Used manipulate the data within those schema objects (DML

Inserting,Updating,Deleting the data, and Querying the database)



1.3.2.7 Servlet

The Java web server is Java Soft‘s own web Server. The Java web server is just a part of a

larger framework, intended to provide you not just with a web server, but also with tools.To

build customized network servers for any Internet or Intranet client/server system.Servlets are

to a web server, how applets are to the browser. About Servlets:

Servlets provide a Java-based solution used to address the problems currently

associated with doing server-side programming, including inextensible scripting

solutions, platform-specific APIs, and incomplete interfaces.

Java-based server. Servlets are to the server-side what applets are to the client-side -

object byte codes that can be dynamically loaded off the net. They differ from applets

in that they are faceless objects (without graphics or a GUI component).

1.3.1.6 MVC Structure

Model

Depending on the type of architecture of your application, the model portion of the MVC

pattern can take many different forms. In a two-tier application, where the web tier

interacts directly with a data store like a database, the model classes may be a set of

regular Java objects. These objects may be populated manually from a result set returned

by a database query or they can even be instantiated and populated automatically by an

Object-to-Relational Mapping (ORM) framework.



View

The views within the web tier MVC pattern typically consist of HTML and JSP pages.

HTML pages are used to serve static content, while JSP pages can be used to serve both

static and dynamic content. Most dynamic content is generated in the web tier. However,

Web applications are considered stateless because the browser doesn‘t typically maintain

an open socket to the web server. However, a web application may still maintainsession

data for a user or even store data within the browser on behalf of the user. Some

applications may require the need for client-side JavaScript. This does not interface or

infringe upon the MVC concept.

Controler

The controller portion of the web tier MVC design is generally a Java servlet. The

controller in a web tier application performs the following duties:

Intercepts HTTP requests from a client.

Translates the request into a specific business operation to perform.

Either invokes the business operation itself or delegates to a handler.

Helps to select the next view to display to the client.

Returns the view to the client.

The Front Controller pattern, which is part of the J2EE Design Patterns, describes how a

web tier controller should be implemented. Since all client requests and responses go

through the controller, there is a centralized point of control for the web application. This

aides in maintenance and when adding new functionality. Code that would normally need

to be put in every JSP page can be put in the controller servlet, since it processes all

requests.The controller also helps to decouple the presentation components (views) from

the business operations, which also aids development.



2. PROJECT MANAGEMENT



2.1 MILESTONES AND DELIVERABLES

The project is planned to complete in a particular time interval for the delivery of

project some milestones are required to indicate status of project.

We have defined it for our project as per requirement and planning. These milestones

are given below:

1. The completion of requirement gathering for project.

-Overview of the Car Centralize System.

Status – Delivered.

2. Detailed study of the Car-Centralize System

-Main Modules of the system.

-Comparing with the existing

system. Status – Delivered.

3. Design the system and represent the system in the form of diagrams.

-Use Case Diagram

-ER-Diagram

-Activity Diagram

-Data Flow Diagram

-Sequence Diagram

-Structure Diagram


4. Database Design.



Status –Delivered.

5. Home Page Design.


6. Registration and Login Module. Status – Delivered.

7. Buyer/Seller and Admin Module. Status – Delivered.

8. Car Details Module.

Status – Delivered



2.2 Risk Management

2.2.1 Risk Identification

Risk Identification is a systematic attempt to specify threats to the project plan.

There are two types of risks are there: Generic and Product Specific. One method for

identifying risks is to create a risk item checklist. The checklist can be used for

identification and focused on some subset of known and predictable risks in the

following generic subcategories:

• Product Size

Risks associated with the overall size of software to built or modified.

• Business Impact

Risks associated with constraints imposed by management or the marketplace.

• Customer Characteristics



Risk associated with the sophistication of the customer and the developer‗s

ability to communicate with the customers in the timely manner.

• Process Definition

Risks associated with the degree to which the software process has been defined

and

Is followed by the development organization.

• Development Environment

Risks associated with the availability and quality of tools to be used to build the product.

• Technology to be built

Risks associated with the complexity of the system to be built and the ―newness..

• Staff Size and Experience

Risks associated with the overall technical and project experience of the

software engineer who will do the work.



2.2.3 Risk Planning

Risk Strategy

Organizational financial

Problems

Requirement problems

Staff illness

Defective components

Requirement changes

Organizationa

l restructuring

Database performance

Underestimated

an

d development time

Prepare a briefing document for senior management showing

how the project is making a very important contribution to

the goals of the business

Alert customer of potential difficulties and the possibility of

delays, investigate buying-in components.

Reorganize team so that there is more overlap of work and

people therefore understand each other‗s jobs.

Replace potentially defective components with bought-in

components of known reliability.

Derive traceability information to assess requirements change

impact, maximize information hiding in the design

Prepare a briefing document for senior management showing hoe

the project is making a very important contribution to the

goals of the business.

Investigate the possibility of buying a higher-performance

database.

Investigate buying-in components, investigate the use of the

program generator.



2.2.4 Risk Monitoring

Risk Monitoring involves regularly assessing each of the identified risks to decide

whether or not that risk is becoming more or less probable and whether the effects of

the risk have changed. Figure gives some examples of factors that may be helpful in

assessing these types of risks.

Risk type Potential indicators

Technology

People

Organizational

Tools

Requirements

Estimation

Late delivery of hardware or support software, many reported technology

problems.

Poor staff morale, poor relationships amongst team members, job

availability.

Organizational gossip, lack of action by senior management.

Reluctance by team members to use tools, complaints about CASE tools,

demands for higher-powered workstations.

Many requirements change requests, customer complaints.

Failure to meet agreed schedule, failure to clear reported defects.



3. SYSTEM ANALYSIS AND REQUIREM



3.1 REQUIREMENT OF THE SYSTEM

The existing "OPEN Auction House" is managed manually. Prior to each auction,

the day of auction, the venue and the items on auction are announced through news media.

Those who wish to take part in the auction have to arrive at the venue on that day on time.

This conventional method most of the times prevent aspiring bidders from

participating in the bidding process. Another headache of the old system is to track each

bidding process and to make it culminate in financial settlement. So the system has to keep

records of both buyers and sellers until the end of settlement. The process is very time

consuming.

TRADITIONAL AUCTION VS. ONLINE AUCTION

Major disadvantages of traditional auctions:

• Limited variety and breadth of goods.

• Buyers are limited to searching through multiple auctions

or traveling to numerous geographically dispersed areas for auctions.

• Inefficient transactions, and high transaction cost.

• Fixed schedules, locations, rules, and auction types.

• Low risk.

Major advantages of online auctions:

• Broader variety of goods and large number of buyers and sellers

• Low-cost of transactions

• Automatic and efficient transactions

• Flexible, convenient, and easy access and participate auctions

• Direct communications between buyers and sellers

• High risk and inefficient item inspection



3.2 SYSTEM FEASIBILITY

The basic idea behind feasibility study is to determine whether the project is feasible

or not. The feasibility is conducted to identify a best system that meets all the requirements.

This includes an identification, description, an evaluation of the proposed systems and

selection of the best system for the job.

The requirements of the system are specified with a set of constraints such as system

objectives and the description of the out puts. It is then duty of the analyst to evaluate the

feasibility of the proposed system to generate the above results. Three key factors are to be

considered during the feasibility study.

OPERATIONAL FEASIBILITY:

An estimate should be made to determine how much effort and care will go into the

developing of the system including the training to be given to the user. Usually, people are

reluctant to changes that come in their progression. The computer initialization will certainly

affected the turn over, transfer and employee job status. Hence an additional effort is to be

made to train and educate the users on the new way of the system.

TECHNICAL FEASIBILITY:

The main consideration is to be given to the study of available resources of the

organization where the software is to be implemented. Here the system analyst evaluates the

technical merits of the system giving emphasis on the performance, reliability, maintainability

and productivity.

By taking the consideration before developing the proposed system, the resources

availability of the organization was studied. The organization was immense computer facilities

equipped with sophisticated machines and the software hence this technically feasible.



ECONOMIC FEASIBILITY:

Economic feasibility is the most important and frequently used method for

evaluating the effectiveness of the proposed system. It is very essential because the main goal

of the proposed system is to have economically better result along with increased efficiency.

Cost benefit analysis is usually performed for this purpose. It is the comparative study of the

cost verses the benefit and savings that are expected from the proposed system. Since

the organization is well equipped with the required hard ware, the project was found

to be economically.



3.3 FEATURES OF THE SYSTEM

The salient features of the site are as follows: 1. PaperlessAuctionSystem

2. It is accessible to everyone at any time no matter where they are. 3. Reliable user validation and checking.

4. Easy online settlement.

An auction is a sale in which a seller presents his product on a public platform/ forum.

The selling price in an auction is determined by the bids made by interested buyers. A bid is

the amount of money proffered for an item that has been put on sale in an auction.

The bidder competes with other potential buyers, keeping in mind that the buyer

with the highest bid is obliged to complete the purchase with the seller. In other words, your

bid tells other buyers, "I want to buy this item at this price."

The price they bid is based on their own valuation of, and need for, the product. The

product is sold to the highest bidder. A potential buyer participates by bidding on an item that

a seller has listed.

You win an auction by placing the winning (read highest) bid and obtaining the item

on auction. The person with the highest bid is the winner of the auction. Now that you're

familiar with how an auction generally works. The person who has offered the highest bid

at close of

auction wins the right to purchase the item at that price.



3.4 MAIN MODULE OF THE SYSTEM

• Registration module:-

Input: Personal information of the user such as username, password, gender, e-mail ID,

address, phone number and other authenticable details.

Output: Confirmation of user registration.

Description: The entered details of the user will be stored into the database and conformation

is given. Then the user can log in with that chosen username as a bidder or

a seller.

• Login Module:-

Input: Log in information such as username and password.

Output: Display the List Of Products.

Description: The user log in into his/her account on the basis of registered username. After log in the user will be redirected to the home page. The products list and

details is shown on that page from which the buyer can choose any product for bidding. The product will be sold out to the maximum bidder until the bid timer expires.



• Buyer/Bidding Module:-

Input: Buyer put the bid for particular bid.

Output: Confirmation of new bid that is put by bidder.

Description

Here one can see the details of any particular product and also the

bidding

history. The user can bid on that item by entering any amount greater than or

equal to the incremental bid amount. Here also system checks to see whether the

user has his credential verified otherwise he/she will be directed to the

login/registration page.

• Seller Module:-

Input: Log in information such as username and

password.

Output: The product is sold out to the winning bidder and the payment is done to the user.

Description: The user log in into his/her account on the basis of registered username.

After log in the user will redirected to the home page. Now the user can put his/her used item or product along with the minimum bid for selling on the website. The confirmation will be given to the seller and at that time the bid

timer starts and the buyer can bid for that product until the bid timer expires.



• Administration module:-

Input: Administrator name and password.

Output: Modify and update the database by the

administrator.

Description: The module is only open to the web administrator due to security reasons. In this module the administrator can add product categories; this is to avoid

rampant creation of categories. The 2nd thing is the option to edit any given product. This will be necessary when some of the details of the product need to be edited for one reason or other. The 3rd and last the closed bid manager

where the administrator notifies both the seller & buyer the need to complete the transactin.



4. SYSTEM DESIGN



4.1 Activity Diagram

Activity diagrams are graphical representations of workflows of

stepwise activities and actions with support for choice, iteration and

concurrency. In the Unified Modeling Language, activity diagrams can

be used to describe the business and operational step-by- step workflows

of components in a system. An activity diagram shows the overall flow of

control.

Activity diagrams are constructed from a limited number of

shapes, connected with arrows. The most important shape types:

rounded rectangles represent activities;

diamonds represent decisions;

bars represent the start (split) or end (join) of concurrent activities;

a black circle represents the start (initial state) of the workflow;

an encircled black circle represents the end (final state).

Arrows run from the start towards the end and represent the

order in which activities happen.



4.1.1 Activity Diagram For Admin

wrong username&

password

[Enter Username,password]

[Failed]

Admin

login

[Success

moved profile]

Dashboard

Logout

Whether admin

wants to manage or

logout

Manage Complain Manage Scheme

Manage Car-Range

Manage Notify buyer & seller

Manage Category

Manage Sub-categoryManage Feedback



4.1.2 Activity Diagram For Seller

[Enter username password]

[Success

Moved Profile]

Seller

Whether Seller

want to continue

editing profile or

logout

Registration

Login

Dashboard

wrong username

&password [Failed]

View/Edit Car Profile View/Edit Complain

Logout

Add Cars



4.1.3 Activity Diagram For Buyer

wrong username&

password

[Enter Username,password]

[Failed]

Buyer

Login

Search Car Detail View Scheme

View Car-Range

View Car Recomandation

Compares Cars

Dashboard

[Success

moved profile]

Logout

Whether buyer

want to continue

editing profile or

logout

Registration



4.2 ER Diagram



ADMINUSER(BUYER/

SELLER)

Registration

LOGIN

CAR COMPLAIN

CAR RANGE

CAR CATEGORY

CAR

SUBCATEGORY

FeedBack

CAR SCHEME

CAR PROFILE

Do

M

1

Can Select

Give

Do

Manage

Do

View

1

1

1

1

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

MManage

Manage

Manage

Manage

Manage

Can Select

Can Select

Can Select

Can Select

Can Select

1

11

1

MM

M

M



Home New Cars SellCars UsedCar Site Map FAQ About

New Car

Car Profile Search Comp-Car

Sell Car

Car Profile Complain Reg/Login

4.3 Structure Diagram

Structured chart of New Cars

Structured chart of Sell Cars



4.4 Use Case Diagram

A use case diagram in the Unified Modeling Language (UML) is a type of

behavioral diagram defined by and created from a Use-case analysis. Its

purpose is to present a graphical overview of the functionality provided by a

system in terms of actors, their goals (represented as use cases), and any

dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are

performed for which actor. Roles of the actors in the system can be depicted.

Use case diagrams depict:

Use cases. A use case describes a sequence of actions that provide

something of measurable value to an actor and is drawn as a horizontal

ellipse.

Actors. An actor is a person, organization, or external system that plays a

role in one or more interactions with your system. Actors are drawn as

stick figures.

Associations. Associations between actors and use cases are indicated

in use case diagrams by solid lines. An association exists whenever an

actor is involved with an interaction described by a use case. Associations

are modeled as lines connecting use cases and actors to one another, with

an optional arrowhead on one end of the line. The arrowhead is often used

to indicating the direction of the initial invocation of the relationship or to



indicate the primary actor within the use case

System boundary boxes (optional). You can draw a rectangle around

the use cases, called the system boundary box, to indicates the scope of

your system. Anything within the box represents functionality that is in

scope and anything outside the box is not.



4.4.1 Use Case Diagram For Admin

Admin

Registration

Login

Manage Car Range

Manage Car Profile

Manage Car Category

Manage Car

Sub.category

Manage Car Scheme

Centralize System

Manage Feedback

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

Manage User

-End1*

-End2*



4.4.2 Use Case Diagram For Seller

Seller

Centralize System

Registration

Login

View/Edit Profile

Add Cars

View/Edit Complain

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*-End1

*-End2

*

-End1

*

-End2

*



4.4.2 Use Case Diagram For Buyer

Buyer

Centralize System

Registration

Login

Search Car Detail

View Scheme

View Car Range

View Car

Recomandation

Compares Cars

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*-End2

*

-End1

*

-End2

*

-End1

*

-End2

*

-End1

*

-End2

*



4.5 Data Flow Diagram

Entity :

Process :

Data Flow

DataStore:



4.5.1 Zero Level

Centralize Sales,Service And Deals

For Automobile Industries

Registration Detail,

SearchBuyer

Manage Category,

Manage Car DetailAdmin

Car DetailSeller

Car datail

Notification From

Interested Buyers

Monthly Inquiry

Report

Buyer

Seller

Admin

Level 0 DFD



4.5.2 First Level

Buyer

Add First name,

Last name

Enter User name

Password

Seller

Admin

Car Detail And

New Car

Provide Scheme

Update Car Detail

Provide Car Detail

manage

manage

manage

manage

Enter User name

Password

Update Category

Update Car Model

Update SchemeScheme Detail

Subcategory

Car Detail

Scheme

Feedback has

been

successfully

submitedGet feedback from admin

Registration

login Search

Car

Add Car

Category

Subcategory

Scheme

Feedback

Welcome

User

Fill Detail

Level-1 DFD



4.5.3 Second Level

User

Category

Car detail

Subcategory

Price Range

Car Detail

View Car

Category

Can Select

View Car

Category

View

Fual types,

Car Company

Can Select

View

Can Select

Can Select

Search

CarCategory

Subcategory

Price

Can Select

View Car

Profile

View Price

Level-2 DFD



4.5.4 Third Level

Admin

Login

Complain

Scheme

Car Range

Notify

Buyers &

Seller

Category

Subcategory

Buyer

Manage

Manage

Manage

Manage

manage

Manage

Manage

Notification

Login

Successfully

Complain has

Been

Successfully

Scheme

Views

Range Detail

Views

Notification

Detail Views

Category

Views

Subcategory

Views

Seller

View

Profile

Modify data

View

Update

Notification

Login

Registration

DetailManage

Use detail

Edit/Delete

Data

Data has been

Successfully change

Level-3 DFD



4.6 Sequence Diagram

A sequence diagram in Unified Modeling Language(UML) is a kind of interaction

diagram that shows how processes operate with one another and in what order. It is a

construct of a Message Sequence Chart. A sequence diagram shows object interactions

arranged in time sequence. It depicts the objects and classes involved in the scenario and

the sequence of messages exchanged between the objects needed to carry out the

functionality of the scenario. Sequence diagrams typically are associated with use case

realizations in the Logical View of the system under development.

Sequence diagrams are sometimes called event diagrams, event scenarios, and

timing diagrams



User Admin System Database

Request For Registration Store Id & Password

Registered

Login Verified

Match Id & passwordlOGIN

Directed to profile

Registered

Login Successfully

Search Car Detail & Add Cars

Return Profile

Required Information match

Information found

Give Complain & Rating

Logout

Edit Profile & Update

Logout

Logout

Successfully Logout

Manage Car Profile

Return Profile



4.6 Data Dictionary Diagram

TABLE 1: Car Info

Column Name Data type Constraint Description

Pro_id Int(10) Primary Key Product identity number

Pro_name Varchar(20) Not Null Name of the product

User_id Int(20) Not Null User identity number

Min_bid

Decimal(20) Must be greater

than zero

Starting amount for a

product

Qty

Int(20) Must be greater

than zero

Number of products

Image_url Varchar(30) Not Null Url of image

Pro_description

Varchar(20)

Not Null Detailed description of the

product

TABLE 2: Feedback


Fax_no Int(10) Not Null Fax number

E-mail Varchar(20) Not Null Email ID of user

Details Varchar(20) Not Null Feedback



TABLE 3: Scheme Info


Order_id Int(20) Primary Key Order Identity number

Pro_id Int(20) Foreign Key Product identity number

User_id Int(20) Foreign Key User identity number

Order_date

Date

Must be In the

form of

DD/MM/YYYY

Date of Order for

Payment

Price

Decimal(20) Must be greater

than zero

Price of a Product

Qty

Int(20) Must be greater

than zero

Number of products

TABLE 4: Buyer Info


User_id Int(20) Primary Key User identity number

Password Varchar(20) Not Null User password

F_name Varchar(20) Not Null User first name

L_name Varchar(20) Not Null User last name



Mail_id Varchar(20) Not Null E-mail id of user

Address Varchar(20) Not Null User address

City Varchar(20) Not Null User city

State Varchar(20) Not Null User state

Country Varchar(20) Not Null User country

Pincode Decimal(10) Not Null User address pincode

Phone_no Decimal(20) Not Null User phone number

TABLE 5: Seller Info















TABLE 6: Admin Info















5. NON-FUNCTIONAL REQUIRMENTS



Security:

- Ensure to provide secured transactions

- Provide secured solutions to protect the online system from: - Active attacks by an intruder

- Any unpredictable termination of transactions - Corruption of data on the network

Privacy:

-Make sure that all information related to buyers and sellers, bids, and offers are protected to

be exposed to other parties, external, public.

Anonymity:

-Make sure that the system should be designed in a way that nobody should recognize the

true identity of the customer unless it is desirable.

Atomicity:

-The auction transactions should be conducted in a way that either it come to a completion,

or terminate without any incomplete transaction.

Low cost:

-The cost of come transaction should be kept as minimal as possible.



6. CONCLUSION



REFERENCES

1. Case Study: Implementing a Web Based Auction System using UML and

Component- Based Programming by Frederick T. Sheldon and Kshamta Jerath.

2. Oriented Modeling and Design wih UML second edition by michael Blaha and James

Rambaugh.

3. E-commerce, Gary P. Schneider, Cengage Learning.

4. Pressman R.S. , Software Engineering : A Practitioner's Approach, TMH.

5. Auction sites for reference : www.Carwale.com , www.google.com ,

www.olx.in , www.biggaddi.com .

http://www.google.com/aclk?sa=l&ai=CvSFSBvjdTpm9OeOl0AG8m-WcAbeGn94Bv6votB2crYUGEAEgxJqxGigCULOfstMCYOXS5IOoDqABkaHZ_APIAQGqBBxP0EziVmMbIRzmmrvMAaZOx8aE3IeZY-7_t19P&num=1&sig=AOD64_1tvMwyZBmRUVIBDSJ2MkL8xtOLTg&adurl=http://as.k.keyade.com/kack/1/%3FkaPt%3Dgoogle%26kaTckM%3Dp%26kaPcId%3D98678%26kaTckId%3D7806168191%26kaAcId%3D2%26kaCpnId%3D%26kaNtw%3Dsearch%26kaKwd%3Dquicker%26kaDmn%3D%26kaTgt%3D%26kaNtw2%3Ds%26kaMtTp%3Db

car centralize

Documents

car sells service

b patel engineering

automobile industries

mehsana page

car info table

spare automobile parts

car sales

buyer info table