Online Vehicle Showroom · PIR MEHR ALI SHAH ARID AGRICULTURE UNIVERSITY RAWALPINDI JULY, 2011. ONLINE VEHICLE SHOWROOM Dedicated to our beloved parents and to all those, whose prayers

Online Vehicle Showroom

Developed

By

Muhammad Qasim

08-arid-1252

Muhammad Shafiq

08-arid-1254

Supervised

By

Madam Bushra

Hameed

Sheraz Akram

Dr. Zia ul Quyyum

MASTER OF COMPUTER SCIENCEMCS

UNIVERSITY INSTITUTE OF INFORMATION TECHNOLOGY

PIR MEHR ALI SHAH ARID AGRICULTURE UNIVERSITY

RAWALPINDI JULY, 2011

ONLINE VEHICLE SHOWROOM

Dedicated to our beloved parents and to all those, whose prayers always pave the way to

success for us.

UIIT, PMAS, UAAR, 2011 Page ii


PROJECT IN BRIEF

Project Title : Online Vehicle Showroom

Site :

Undertaken By : Muhammad Qasim

Muhammad Shafiq

Supervised By : Madam Bushra Hameed

Date Started : 15-03-2011

Date Completed : 20-07-2011

Technologies Used : Visual Studio 2008,

SQL Server Management Studio2005

Operating System : OS Window XP 2006

Web Server : IIS (Internet Information server)

Hardware Used : GSM Device (SONY ERICSSON W580i)

Dell Latitude D630

(CPU: 2.0MHz, RAM: 2 GB & Hard Disk: 160 GB)

ACKNOWLEDGEMENT

UIIT, PMAS, UAAR, 2011 Page iii


Thanks to Almighty Allah for giving us knowledge, power and strength

to accomplish this task. We learned a lot while doing this project and

this will certainly help us in our forth coming life. Many friends of us

helped us during this project but we are really thankful to Madam

Bushra Hameed from University Institute of Information Technology,

who helped us in all the phases of this project. Her supervision helped

us a lot during the times of difficulties. In the end we would like to

thank all of our Teachers and friends for their support and

encouragement.

MUHAMMAD QASIM

MUHAMMAD

SHAFIQ

UIIT, PMAS, UAAR, 2011 Page iv


DECLARATION

We hereby declare that this software, neither as a whole nor as a part

has been copied out from any source. It is further declared that we

have developed this software and accompanied report entirely on the

basis of our personal efforts. If any part of this project is proved to be

copied out from any source or found to be reproduction of some other.

We will stand by the consequences. No portion of the work presented

has been submitted in support of any application for any other degree

or qualification of this or any other university or institute of learning.

MUHAMMAD QASIM

MUHAMMAD

SHAFIQ

UIIT, PMAS, UAAR, 2011 Page v


CERTIFICATION

It is certified that the contents and form of the project entitled “Online

Vehicle Showroom” submitted by Muhammad Qasim (08-arid-1252)

and Muhammad Shafiq

(08-arid-1254) has been found satisfactory for the requirements of

University Institute of Information Technology

PMAS - Arid Agriculture University,

Rawalpindi

For the award of the degree of

MASTER OF COMPUTER SCIENCE

MCS

Supervisor: ________________________ Madam Bushra Hameed

Member 1: ________________________ Mr. Sheraz Akram

Member 2: ________________________ Mr. Ghulam Mustafa

Dated: ______________ Director: ________________________ Dr. Zia ul Quyyum

UIIT, PMAS, UAAR, 2011 Page vi


ABSTRACT

The “Online Vehicle Showroom System” a web application is

intended to provide complete solutions for vendors (Seller) as well as

customers (Buyers) through a single gateway i.e. using the internet

as the sole medium. It will enable vendors to put their vehicles online

for shopping, customer to browse through the System and purchase

the vehicles online without having to visit the showroom physically. If

users fails to find the vehicle of their choice they can put their

request, whenever vehicle of their choice is available they will be

informed by Email/ SMS. The system also provides the facility of

advertisements and discussion forum as well.

TABLE OF CONTENTSPage #

University Institute of Information Technology....................................................viPMAS - Arid Agriculture University,......................................................................vi

UIIT, PMAS, UAAR, 2011 Page vii


Rawalpindi...........................................................................................................vi

PROJECT OVERVIEW..................................................................................1

TOOLS & TECHNOLOGIES USED..................................................................6

3.1 INTRODUCTION.................................................................................12

3.1.1 PURPOSE ....................................................................................................12

3.1.2 DOCUMENT CONVENTIONS.............................................................................12

3.1.3 INTENDED AUDIENCE AND READING SUGGESTIONS............................................13

3.1.4 PROJECT SCOPE............................................................................................13

3.1.5 REFERENCES................................................................................................14

3.2 OVERALL DESCRIPTION......................................................................14

3.2.1 PRODUCT PERSPECTIVE..................................................................................14

3.2.2 PRODUCT FEATURES.....................................................................................15

3.2.3 USER CLASSES AND CHARACTERISTICS............................................................16

3.2.4 OPERATING ENVIRONMENT............................................................................16

3.2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS...................................................16

3.2.6 USER DOCUMENTATION.................................................................................17

3.2.7 ASSUMPTIONS AND DEPENDENCIES..................................................................17

3.3 SYSTEM FEATURES............................................................................17

3.4 EXTERNAL INTERFACE REQUIREMENTS...............................................18

USER INTERFACES.................................................................................................18

HARDWARE INTERFACES.........................................................................................19

SOFTWARE INTERFACES..........................................................................................19

3.6 COMMUNICATIONS INTERFACES..........................................................................20

3.7 OTHER NONFUNCTIONAL REQUIREMENTS...........................................23

3.7.1 PERFORMANCE REQUIREMENTS.......................................................................23

3.7.2 SAFETY REQUIREMENTS.................................................................................23

3.7.3 SECURITY REQUIREMENTS..............................................................................23Only the authorized person can access the database connected with the Server. Access person can update or delete it................................................................243.7.4 SOFTWARE QUALITY ATTRIBUTE....................................................................24

Reliability.....................................................................................................................24Flexibility.....................................................................................................................24Performance & Ease of use..........................................................................................24Maintainability.............................................................................................................24

UIIT, PMAS, UAAR, 2011 Page viii


Interoperability............................................................................................................24Portability....................................................................................................................24Database.....................................................................................................................24

TEST OBJECTIVES....................................................................................67

6.2 TESTING PROCESS.............................................................................68

7.1 ACHIEVEMENTS.....................................................................................124

7.2 LIMITATIONS...................................................................................................125

7.3 FUTURE WORK...............................................................................................125

UIIT, PMAS, UAAR, 2011 Page ix


Chapter 1

INTRODUCTION

PROJECT OVERVIEW

This online system facilitates the users to sale and purchases

their vehicles. Sellers who want to sale their vehicles they

have to register and then provide their vehicle’s information

from basic features to extra features along with vehicle’s

photos. Buyers can view vehicle’s information of their choice.

The system has following features

1.1.1User Registration

Users have to register before buying, selling, placing ads,

placing bids and taking part in discussion forum through user

registration form.

1.1.2Selling & Buying Vehicles

Sellers provide their vehicle’s information from basic features

to extra features along with vehicle’s photos. Buyers can view

vehicle’s information of their choice.

1.1.3Sending Email/SMS

This module provides the facility to sellers/buyers to inform

by e-mail as well as SMS.

It means that whenever a buyer’s choice not found he/she

can put request and if his/her choice is uploaded then the

informed by email/SMS.

1.1.4Vehicle Bidding

UIIT, PMAS, UAAR, 2011 Page 1


Any user can place bid to sale his/her vehicle. The system

will provide both options i.e. normal sale as well as bidding

sale.

1.1.5User Friendly Search

i. This module provides the facility to visitors to search the

vehicles of their particular choice.

ii. No account management or registration is done for visitors.

iii. If any visitor selects any vehicle to purchase then it will

treated as a buyer and will be registered.

1.1.6Discussion Forum

Sellers and buyers can discuss their issues about

vehicles such as price (actual market value), faults,

fraud cases, vehicle industry updates, motor shows and

related events etc.

1.1.7 Advertisements

Any user can place advertisement including general ads,

vehicle sale ad, vehicle buying ad and bid ad

1.2 PROJECT SCOPE

A web application is intended to provide complete

solutions for vendors (Seller) as well as customers

(Buyers) through a single gateway i.e. using the internet

as the sole medium. It will enable vendors to put their

vehicles online for shopping, customer to search through

the System and purchase the vehicles online without

having to visit the showroom physically. It will save time

consumed in manual purchasing. It will also facilitate the

client without profit and loss.

1.3 PROJECT OBJECTIVES



Following are the main objectives of our system:

i. Advance Search & User Friendly Engine.

ii. Increase website audience.

iii. Buyer and seller can add and edit listings without any HTML knowledge

and less work (not lengthy procedure).

iv. Photos are automatically resized and optimized.

v. Help includes a step by step Wizard and detailed User Manual.

vi. User account manager

vii. Multiple account types

viii. Customizable account privileges

ix. Support for an unlimited number of vehicles registration in an account.

x. Customizable listing feature fields

xi. Modular code construction for easy site integration

1.4 PROPOSED SOLUTION

In this project

• We are intended to develop a solution to sale & purchase

vehicles

• We are going to propose a solution for those who don’t want

to go to vehicle dealers; they will be informed by E-mails/SMS.

• We are also providing a communication in the form of sending

SMS from computer to mobiles.



Fig 1.1 System architecture

1.5 PROPOSED SYSTEM COMPONENTS

Our proposed solution has following components


User (Admin, Seller, Buyer, Mechanic)

POP3, SMTP and HTTP

HTTP

Web Browser

User PC

Windows OS

I IS

Server (Mainframe)

Web Server

Win d o wsSer ver

SMS Gateway

SQLd at abase

Mic r o so f tSQL ser ver

2005

Database Server

ADO. Net

mo bi l e

Emai lSer ver

GSM


1.5.1 GSM device:

GSM (Global System for Mobile Communications) is second

component of our proposed System and it is responsible for sending

and receiving SMS to and from the users. Server will extract SMS

from GSM device and send SMS to the GSM device.

1.5.2 Web server:

IIS (Internet Information server is used as a Web server)

1.5.3 Microsoft SQL Server

To maintain information of the system SQL Database Server 2005

will be used.

1.5.4 Email Server

Email server will be used to send emails to sellers as well as buyers


BuyerBuyer SellerSeller

Cell PhoneCell PhoneCell PhoneCell Phone


1.5.5 Database:

Database component is use to store the information of users and

also to maintain the log of sending and receiving Emails.

TOOLS & TECHNOLOGIES USED

OS Window XP

Visual Studio.net 2008

Microsoft SQL Server 2005

Mcore (SMS Sending and Receiving)

Sony Ericsson/Nokia PC Suite

Internet Explorer 7, Mozilla Firefox3.5

Hardware: GSM Device (SONY ERICSSON W580i)

Dell Latitude D630

(CPU: 2.0MHz, RAM: 2 GB & Hard Disk: 160 GB)



Chapter 2

LITERATURE REVIEW

2.1 Literature review

Consumers prefer to go to the Internet to shop for a vehicle to

get information to make a buying decision without having to visit a

dealership. Sometimes they turn to the World Wide Web vs. their

local car row to avoid being pressured by a self serving car

salesperson -- real or imagined. Other times their objective may be

to save gas and time before they jump into the real world where

they may be pressured into making a premature buying decision

based on emotion and limited information. Frankly, in many cases,

they are right; can you say -- spot delivery.

Job one for search engines, like Google, is to provide relevant

information to their online customers to help them narrow down

their list of vehicles of interest and answer associated questions like

trade-in value, payment options and the many items that must be

addressed before they can select -- the -- vehicle vs. -- a -- vehicle.

Once those issues are resolved, they need to help their online

shoppers find an auto dealer that can provide a vehicle that best

satisfies those terms and conditions; in that order -- vehicle first and

dealer second. My point is that when Google first directs their

customers to the most relevant source for their desired information

it is not necessarily limited to a particular dealership. Today's car

shoppers are much better educated than yesterday's. They know

what questions they need to ask before they can make a buying

decision so their online search words are more able to target

vehicles that warrant their consideration rather than limiting their

search to their local car dealerships. For better or worse, auto

dealers can't put that horse back in the barn!



The adversarial relationship between consumers and auto

dealers that governed old world selling processes originated in the

real world to help auto dealers control the shopping and negotiation

process and they survived briefly on the virtual showrooms being

built one on the Internet, but -- today and tomorrow -- not so much!

Once auto dealer's realized -- or more correctly -- once customers

told auto dealers that they no longer controlled the access to the

information that they needed to purchase a vehicle the dealers tried

to control the information on the Internet; how is that working out

for auto dealers!

Automotive advertising agencies first assumed that S.E.O. and

S.E.M. was a way to put Google on the auto dealer's side of the

Internet Super Highway. If they placed the right search words, meta

tags, URL names -- and the various manipulations of the Google

search algorithms that automotive advertising agencies have

memorized as fast as Google changes them -- then they could

manipulate the search results to place their auto dealer clients as

the most relevant source for the information that customers were

searching for and earn the auto dealers a position on the car

shoppers short list. Given the vertical priority placed by Google to

position a listing on page one based on relevancy to their customers

search words or phrases, that technique certainly has value.

However, since customers are prioritizing finding a vehicle before a

dealer and/or to answer related questions before they open

negotiations on a specific vehicle at a particular auto dealer, auto

dealers that base their online marketing efforts to accomplish that

priority are positioning themselves mid-sales cycle and they may be

a day late and a dollar short for a large portion of today's and

tomorrow's shoppers/buyers.

Automotive advertising agencies have attempted to answer

customer's questions on their auto dealership' websites in an

attempt to earn them a top position on vehicle based searches.

Their assumption is that the more information the better -- as long



as it is relevant -- however, once at the auto dealer's site the more

accurate priority is "transparency!" More time on page, and more

page visits used to be considered a good thing but today, once

again -- not so much! The easier and faster the online car shopper

can find the specific information that they need to make a buying

decision the better! Site designs are being simplified with more

intuitive user interface and dedicated landing pages or linked micro

sites to allow customers to limit the amount of "clicks" or wasted

exposure to information that may be relevant to the dealer but not

necessarily to the customer; at that time in their shopping cycle at

least.

Once the shopper actually ventures onto an online showroom

the plan is to keep them there by providing direct or linked access

to anything that they need to move themselves further down the

sales/buying funnel. The dealer may see these information

resources as a conversion tool or a lead generator but if they lose

track of the truth -- that the customer is still in charge -- they risk

losing them with the click of a mouse. Sorry, but throwing their

trade-in keys onto the roof won't work in your virtual showrooms!

The solution is for auto dealers to listen and learn from their

online customers before they presume to sell them anything!

Human nature has survived on the World Wide Web and relationship

based selling still has a strong influence on consumers. Today's

online shoppers are being directed by Google and the other search

engines to social networking sites because the marketplace is a

conversation and people are social animals. Auto dealers who want

to attract customers with a message that they are the best source

for information to serve the customer's interest vs. their own are

better served to have their customers make that case for them.

Next generation inventory based search portals -- like

ronsmap.com -- accept an auto dealer's inventory for free with the

ability to push their vehicles into social media using their vBack



application to Ask-A-Friend or Tell-A-Friend about the vehicle -- and

the dealer --that they are considering within their social networking

communities of online friends. Google has already admitted that

they are prioritizing real time social media to establish relevancy,

and automotive advertising agencies already know that more

vehicles on a site provide more relevancy to more online car

shoppers. As a result, they have found that the way to attract more

online customers to find their auto dealership as the place to go to

get all of their questions answered will be the message that is

carried along with their individual vehicles listed on this communal

consumer-centric site; which is what the customers are looking for

to begin developing their shortlist of dealers to do business with!

Customer friendly applications that distribute the information

on an auto dealer's individual website which have the secondary

value of functioning as a conversion tool or lead generator are also

key differentiators that quickly build branding value for an auto

dealer's virtual showroom and enhance their online reputation as

the place to go to get customer's questions answered vs. their being

sold something. For example, GetAutoAppraise.Com is a next

generation appraisal tool that provides credible third party trade-in

values sourced through NADA with integrated inventory information

that allows the customer to review the entire transaction more

efficiently. Their trade-in appraisal form includes vehicle, price and

payment information to and from both parties to the transaction in

one easy transparent and customer friendly process.

Video platforms, like SiSTeR Technologies Video CarLot, is

another transparent Google friendly application that converts

pictures on an auto dealer's website into interactive videos with

human voice that are also pushed out onto the World Wide Web

through their dedicated API to You Tube and soon to be announced

applications that push their vShock platform onto social networking

communities like Face Book. Their proprietary video platform is fully

index able for the search engines and it provides relevant



information to the customer from within the video as well as direct

links through their vShock application that opens a dedicated micro

site with similar vehicles chosen from the dealer's inventory using

algorithms and business rules custom designed by the dealer to

improve the customers vehicle selection. This process is another

example of a customer friendly information delivery system that will

improve transparency for the customer once they find an online

dealership which will also extend the auto dealers S.E.O..

The point is, the more information that an automotive

advertising agency provides through their auto dealer client's

websites in the most relevant and transparent manner the better.

However, auto dealers need to get online car shoppers to find and

visit their virtual showrooms first, and since information is a key

differentiator between them and their online competition -- or

according to Google and online shoppers, it should be - then the

information alone won't make it! Automotive advertising agencies

must focus on consumers' interests in order to best serve their auto

dealer clients because Google does; and Google does it because

their customers demand it!

C# (pronounced "see sharp") is a multi-paradigm programming

language encompassing imperative, functional, generic, object-

oriented (class-based), and component-oriented programming

disciplines. It was developed by Microsoft within the .NET initiative

and later approved as a standard by Ecma (ECMA-334) and ISO

(ISO/IEC 23270). C# is one of the programming languages designed

for the Common Language Infrastructure.

C# is intended to be a simple, modern, general-purpose, object-

oriented programming language. Its development team is led by

Anders Hejlsberg. The most recent version is C# 4.0, which was

released on April 12, 2010.for c# help we study the following books



Chapter 3

REQUIREMENT ANALYSIS

3.1 Introduction

3.1.1 Purpose

The “Online Vehicle Showroom System” a web application

that is intended to provide complete solutions for vendors

(Seller) as well as customers (Buyers) through a single gateway

i.e. using the internet as the sole medium. It will enable vendors

to put their vehicles online for shopping, customer to browse

through the System and purchase the vehicles online without

having to visit the showroom physically. If users fails to find

the vehicle of their choice they can put their request, whenever

vehicle of their choice is available they will be informed by

Email/ SMS.

This document is meant to delineate the features of OVS, so as

to serve as a guide to the developers on one hand and a

software validation document for the prospective client on the

other.

3.1.2 Document Conventions

Throughout this document, the following conventions have been

used: -

Font: Sylfaen

Size: 18 for Main Headings (Bold)

Size: 14 for Sub Headings (Bold)

Size: 12 for the rest of the document.



3.1.3 Intended Audience and Reading

Suggestions

This document is intended to serve the needs of the mobile users

mainly. This document will help developers, testers and project

manager to develop the project according to the user requirements

specified in this document.

User Type DescriptionProject

Manager

It will help the Project Manager to manage the

overall activities of project.

DevelopersIt will help the developers to develop the system

according to the specifications or requirements.

Testers

Testers will test the system according to the

specifications and requirements mentioned in this

document.Marketing

Managers

It will help Marketing manager to advertise the

product.Document

Writer

It will help document writer to write detailed

document. Table 2.1 Intended audiences

It could be of great use to the all type of mobile users. It aims at

describing the approach to the development of the Text to speech

tool and the procedures to implement it in mobile phones. So far,

there has been no significant advancement on this idea which is

relatively new but could be a great commercial success.

3.1.4 Project Scope

A web application is intended to provide complete solutions for

vendors (Seller) as well as customers (Buyers) through a single

gateway i.e. using the internet as the sole medium. It will

enable vendors to put their vehicles online for shopping,



customer to search through the System and purchase the

vehicles online without having to visit the showroom

physically. It will save time consumed in manual purchasing. It

will also facilitate the client without profit and loss.

3.1.5 References

• http://www.digitalfuturesoft.com/texttospeechproductsforpock

etpc.php

• http://www.w3.org/2004/09/ssml-pressrelease.html

• http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/

• http://www.ispeech.org/ap

• http://www.smartmuseum.eu/del/D3.1b_SM.pdf

• http://www.carcitysupercenter.com/

• http://www.usedcarshowroom.co.uk/

• http://www.usedcarshowroom.co.uk/

• Karl E. Wiegers SRS FORMAT (IEEE)

3.2 Overall Description

3.2.1 Product Perspective

This system is a follow-on member of existing online showrooms’

product family providing the facilities for bidding their vehicles. The

pictorial overall system as follows


http://www.carfax.com/http://www.usedcarshowroom.co.uk/http://www.carcitysupercenter.com/http://www.smartmuseum.eu/del/D3.1b_SM.pdf


Fig 3.1 Product Perspective

3.2.2 Product Features

The proposed systems make use text of SMS and E-mail and

facilitate the user to listen it instead of reading it by them.

• Buyer’s Registration if he/she wants to buy vehicle

• Seller’s Registration if he/she wants to sale vehicle

• User Friendly Search

• Sending Emil/SMS

• Advertisements

• Bidding Vehicles


BuyerBuyer SellerSeller

Cell PhoneCell PhoneCell PhoneCell Phone


• Discussion Forum

3.2.3 User Classes and Characteristics

i. Buyers can search vehicles of their choice and put their

requests to be informed later email/SMS when choice will be

available.

ii. Sellers can upload their vehicle’s information including

pictures, model, manufacturer etc.

iii. Sellers can sale their vehicles on bid if they wish.

iv. Casual visitors can visit the site to check for their choice.

3.2.4 Operating Environment

3.2.4.1 Hardware Specifications

Server with Pentium IV, 1GB of RAM

GSM device

Mobile Phone

3.2.4.2 Software SpecificationsServer with Windows Server 2006

IIS (Internet Information Server)

3.2.5 Design and Implementation Constraints

This section will indicate the design constraints that apply on the

system being developed and that shall be adhered to during the

development phase of the project.

Programming languages: The server programming that resides

on the Server shall be written in C# (Dot Net) using the Framework

(3.5) development kit.

Database: Microsoft SQL Server 2005 shall be used as the system’s

database management system. The database shall be stored on the

server. Development tools: The Microsoft Visual Studio 2008 and the

NetBeans2 6.7 IDE shall be used as the primary development tools

to build the server and client programs.



Standards: The server program shall be able to work under

Windows Server 2006, Windows XP etc. operating systems. The

server requires that the 3.5 Framework to be installed on the

Server. The Server hardware specifications must meet the minimum

requirements of 2.0 GHz CPU speed, 1 GB of RAM, and at least 20

MB of hard disk space for database storage. The client program

shall be able to function on all mobile phones that have the Java

Runtime Environment installed. GSM device should be used to send

and receive the SMS and E-mails.

Communication Protocols: The system should use the SMTP

(Simple Mail Transfer Protocol) and POP (Post Office Protocol) etc.

protocols to send and receive the E-mails and SMS.

Sustainability: The system is expected to live whenever needed.

3.2.6 User Documentation

User Manual will be provided with this tool. In those manuals the

complete guidance regarding to use this application will be provided

to the users.

3.2.7 Assumptions and Dependencies

It is assumed that the user possess a Java enabled mobile phone.

It is assumed that the text is in formal English only. It is important

for the text to speech conversion as well as the working of the

system.

3.3 System Features

The following modules/ features are in the system’s

scope

• Buyer’s Registration



• Seller’s Registration

• User’s Friendly Search for casual visitors can visit

the site to check for their choice.

• Sending Emil/SMS

• Advertisements

• Discussion Forum

• Vehicle Bidding

• Request For Vehicle

3.4 External Interface Requirements

User Interfaces

The User interface shall consist of various modules designed to help

you manage the system. Each module shall be representing a set of

questions. This would enable to work more efficiently. Record types

shall be related to one another.

The user interface for the system will be run on Server. A prototype

has been created that represents the final interface for the system

in terms of look and feel. The user interface will be limited to the

types of controls that can be generated using .NET controls. The

user interface code will be generated by individual developers, as

well as by the Microsoft Visual Studio Integrated Development

Environment.



Hardware Interfaces

The Hardware Interfaces of the system are handled by the Windows

Server 2006 Operating System, which is connected to the Internet.

GSM4 Device is another hardware component to communicate

between sending and receiving SMS. E-mails are sent to the user as

an SMS through the GSM device using SMTP protocol. User can reply

the E-mail as an SMS through the GSM device. The data will be use

by the GSM device for sending and receiving SMS. This device

communicates with the Server and Server is attached to the central

database.

Software Interfaces

• Operating System

The software is being designed to run on Windows Server 2006.

Windows Server 2006 includes the latest version of Internet

Information Services, version 8.0.

• Server

The software runs on the Server and can extract all the

E-mails from the Internet Server.

• Database

The software will access the Microsoft SQL Server 2005 Enterprise

Edition database for the following features.

Database can hold the following data.

ID of each User.

Phone Numbers of the Users.



E-mail address of the Users.

Maintain Log for each SMS and E-mail and also maintain Chatting Log.

• Libraries

The software will be created using the Microsoft .NET version 3.5

Framework and also use Mcore or Ozeki 2009 for SMS interaction.

• Interface Layout Tools

Based on requirements, the group has selected Microsoft Visio 2007

for designing the UML diagrams. The necessary Interface layout

functionality is design using Adobe Photoshop 7.

3.6 Communications Interfaces

Following are the communication functions required for

communication with the Server and sending and receiving SMS

through GSM device.

• SMTP (Simple Mail Transfer Protocol) and Pop (Post Office Box)

etc. protocols are required to send and receive the SMS and E-

mails.

• GSM (Global System for Mobile Communications) device is

required to send and receive the SMS through Server.

• Server is required to send and receive E-mails from the

Internet.

• Windows Server 2006 should be installed on Server to get fast

and accurate data transfer.

• The security issues in Internet E-mail include secrecy, content

integrity, and identity integrity.



3.7 Functional RequirementsAbove described features will have the following requirements?

o Buyer’s Registrationi. Buyer need to register before use the facilities to buy any

vehicle.

ii. All the information will be kept in database that includes

buyer’s particulars and required vehicle as well as its buying

(price) range.

iii. It also contains the record of bought vehicle by a particular

person.

o Seller’s Registrationi. Seller need to register before use the facilities to sale any

vehicle.

ii. All the information will be keep in database that includes

seller’s particulars (Name, Contact No. etc) and required vehicle

as well as its buying (price) range.

iii. It also contains the record of sold vehicles by a particular

person.

o User Friendly Search



i. This module provides the facility to visitors to search the

vehicles of their particular choice.

ii. No account management or registration is done for visitors.

iii. If any visitor selects any vehicle to purchase then it will

treated as a buyer and will be registered.

o Sending Emil/SMS

i. This module provides the facility to sellers/buyers to inform

by e-mail as well as SMS if case of seller/buyer response.

ii. It means that whenever a buyer’s choice not found he/she

can put request and if his/her choice is uploaded then the

informed by email/SMS.

o Advertisements This module provides the all facilities

concerning to advertisements based on

priorities defined by payment/cost.

o Vehicle Bidding Any seller can add bid to sale his/her vehicle.

The system will provide both options i.e.

normal sale as well as bidding sale.

o Discussion Forum

Sellers and buyers can discuss their issues

about vehicles such as price (actual market

value), faults, fraud cases etc.



3.7 Other Nonfunctional Requirements

3.7.1 Performance Requirements

• Response time for a sending and Receiving the SMS and E-

mails - average: maximum: 30 seconds. A response time

sending one E-mail or receiving one SMS.

• Throughput – an average of 2 transactions per minute.

• Capacity– the system can communicate with 100 mobile

users at the same time.

• Degradation mode - If the system is degraded when we

exceed 100 mobile users, we will remain in the normal

mode of operation with longer response time.

3.7.2 Safety Requirements

The following is a list of the safety requirements to indicate how the

system shall prevent any possible threat to system.

The system can send the E-mails to the required persons. The

system should have ability to check for required person from the

database.

3.7.3 Security Requirements

The following is a list of security requirements that indicate how the

system shall protect itself and its sensitive data and

communications from accidental, malicious, or unauthorized access,

use, modification, or destruction.

• The system shall not permit unauthorized persons to

access or participate in any activity started by the

server and client.

• The system shall not allow confidential data stored in

the system’s database to be accessed, whether directly

or indirectly, by client (mobile) users.



Only the authorized person can access the database

connected with the Server. Access person can update

or delete it.

3.7.4 Software Quality Attribute

Reliability

No interruption should be occurring wile sharing

information with each other.

Flexibility

Any module should be enhanced and added.

Performance & Ease of use

The Software will user friendly and enhance performance while

conducting Risk Assessment.

Maintainability

Any module can be maintainable individually. The application will be

easy to maintain and upgrade due to the use. The application will be

developed in modular structure so it will be easy to manipulate the

development process, testing, and maintainability.

Interoperability

The system will have interoperability with the other modules and to

Interact and function with other products or systems, without any

access or implementation restrictions.

Portability

The system can run on all kinds of mobile phones.

Other Requirements

Database

System can have small database which can store the E-mail address

as well as the phone numbers of corresponding E-mails. The



database can also maintain the history of E-mail to SMS and SMS to

E-mails conversions.

3.8 Appendix A: Glossary

This solely describes those terms which have been used with special

meanings, with reference to context.

1. .NET

This application can be develop in .NET Framework 3.5 with

C# and runs on Server.

2. GSM

GSM (Global System for Mobile Communications: originally from

Group Special Mobile) is the most popular standard for mobile

telephony systems in the world. This device is used to send and

receive SMS.



Chapter 4

SOFTWARE DESIGN

4.1 Use Case Diagram

4.2 Fully Dressed Use Cases

4.3 Domain Model

4.4 Class Diagrams

4.5 Activity Diagram

4.6 Sequence Diagrams

4.7 Operational Contracts

4.8 Deployment Diagrams

4.9 Entity Relationship Diagram



4.1 USE CASE DIAGRAM

4.1.1 Use case Model


Admin

Mechanic

Visitor

Buyer

Register

Seller

Place Bid

PlaceAdvertisement

Manage Bid Manage Ads

Post Add

Send Bid info

Make Payment

Send SMS SendE-mail

RemoveAddSearch Vehicle

View OverallHistory

View BidHistory

View vehicleHistory

Buy Vehicle

Verify card

DeleteMessages

Manage Forum

Finalize Bids

Pay Bid Fee

Authentication

ForumFeedback

CommentsVehicle

Condition

SystemGenerated(automatic)

SearchVehicle

Mechanic

Refundableif bid fails


Sale Vehicle

SendE-mail

Send SMS

if desiredvehicle not

found

Put Request

InformBuyer

UploadVehicle Info

if any buyeris waiting <

<in

clude

>>

<<in

clude>>

InformBuyer

View Vehicleinfo

RateMechanic

SearchCriteria


4.2 FULLY DRESSED USE CASES

Use Case section Comment

Use Case name Vehicle Searching

Scope Online Vehicle Showroom System

Level User goal

Primary actor

(Unregistered )Visitor

Stake holder and their

interest

Casual users: Want to search the vehicle of

their choice

Precondition Internet connection

Success guaranteeThe user will be able to search the required

information

Main success scenarioThe system will provide fast and efficient

searching

Extension

1. User can be registered to sale,

purchase, place advertisement etc

2. User can place bid

3. User can view bid history

Special requirementUser should have basic knowledge of using

internet (browsing)

Technology and data

variation listInternet connection , HTML,ASP

Frequency of

occurrenceWhenever any user want to visit the site



Table: 4.2.1 Searching the Site (All Users/Visitors)


Use Case section Comments

Use Case name Visitor Registration


Level Sub Function

Primary actor Visitor


interest

Casual users: Want to register to become a

regular user

Precondition The user will make a Request for registration

Success guaranteeThe user will registered to access full

functionality

Main success scenarioThe user will registered to access

functionality

Extension

1. After registration user will be informed

by SMS/ Email about user name &

password

2. User will be informed by SMS/ Email

about vehicle sale, purchase, bidding etc

Special requirementUser should have basic knowledge of using

internet (browsing)

Technology and data


Frequency of

occurrenceWhenever user request for registration


Table: 4.2.2 User Registration (All Users/Visitors)


Use Case section Comments

Use Case name Visitor Registration


Level Sub Function



interestCasual users: Want to register to become a regular user

Precondition The user will make a Request for registration

Success guarantee The user will registered to access full functionality

Main success scenario The user will registered to access functionality

Extension

1. After registration user will be informed by SMS/ Email about user name & password

2. User will be informed by SMS/ Email about vehicle sale, purchase, bidding etc

Special requirementUser should have basic knowledge of using internet

(browsing)

Technology and data


Frequency of occurrence Whenever user request for registration


Table: 4.2.3 User Registration (All Users/Visitors)

Use case section Comments

Use Case name View overall history


Level Sub Function


Stake holder and their interestAll users: Registered as well as unregistered

Interest : To view overall history including

PreconditionUser may want to place a bid, advertisement, buy or sale

vehicle

Success guarantee The user will registered to access full functionality

Main success scenario 1. The user will registered to place bid

Extension

1. After registration user will be informed by SMS/ Email about user name & password

2. User will be informed by SMS/ Email about

vehicle sale, purchase, bidding etc

Special requirement Registration is required to place bid

Technology and data variation list Internet connection , HTML,ASP

Frequency of occurrenceWhenever any user want to view the history or when the

user want to place the bid



Table: 4.2.4 View Bid History (All Users/Visitors)

Use case section Comment

Use Case name Manage Advertisements


Level Sub Function

Primary actor Administrator

Stake holder and their interest

Administrator: To manage Advertisements

Interest : To place new advertisements and to remove old advertisement

PreconditionAdministrator’s Authentication or advertisement

placement

Success guaranteeAdministrator will manage Ads after registration &

authentication

Main success scenario

Managing Advertisements efficiently i.e.

• Posting advertisements

• Removing advertisements

Extension1. To place new advertisements

2. To remove old advertisement

Special requirement Administrator’s Registration & authentication

Technology and data variation listInternet connection , HTML,ASP

Ads may in image as well as video animation format

Frequency of occurrence

Whenever a new advertisement is to be placed

OR

Whenever an old advertisement is to removed

Table: 4.2.5 Manage Advertisements ( Administrator )



Use Case section CommentUse Case name Manage Bids


Level Sub Function



Administrator: The authorized personInterest : To manage bids

Precondition Administrator’s Authentication

Success guarantee Administrator will manage bids after registration & authentication


Managing bids i.e.

• Finalizing bids and informing users

• Bid announcement

• Removing bids

Extension 1. Finalize bids2. Send bid information (SMS / Email)

Special requirement Administrator’s Registration & authentication

Technology and data variation list Internet connection , HTML,ASP

Frequency of occurrence

Whenever a new bid is to be placed

OR

Whenever an old bid is to removed

Table: 4.2.6 Manage Bids ( Administrator )



Use Case section Comment

Use Case name Manage ForumScope Online Vehicle Showroom SystemLevel Sub function


Stake holder and their interestAdministrator: To manage forum

Interest : Remove unwanted messages & comments

Precondition Administrator’s Authentication

Success guaranteeAdministrator will manage forum after registration &

authentication


• When users have to place comments and

messages log in is required

• It requires registration

Extension

1. Check the comments on the forum and remove

unwanted messages.

2. To provide feedback about fake users and bids

Special requirement Administrator’s Authentication

Technology and data variation

listInternet connection , HTML,ASP

Frequency of occurrence Once in a day to check and remove unwanted messages

Table: 4.2.7 Manage Forum ( Administrator )



Use Case Section Comment

Use Case name Inspect vehicle’s condition


Level Sub function

Primary actor Mechanic


Mechanic: The registered & authorized person

Interest : To check the vehicle’s condition and to

comment

PreconditionAuthorized person

If sellers want to put comments about their vehicle

Success guarantee To check the vehicle’s condition and to put comments


• Inspect the vehicle if the seller wants to put

comments about condition.

• Log in and place the comments

Extension1. Check vehicle’s condition

2. Comment about the vehicle and

Special requirement The registered & authorized person

Technology and data variation list Internet connection ,HTTP, HTML, ASP

Frequency of occurrenceWhen sellers want comments or mechanic want to

inspect vehicle

Table: 4.2.8 Vehicle Inspections (Authorized Mechanic)




Use case name Sale Vehicle


Level User goal

Primary actor Seller


interest

Sellers: The registered users

Interest : Want to sale the vehicle

Precondition User have to log in to sale vehicle

Success guarantee The sellers can sale their vehicles


1. Online user select sale vehicle option

2. They have to upload complete vehicle info

3. Mechanic’s comments increases reliability and chances of

selling vehicle

Extension

1. When online user select sale vehicle option

2. The system will prompt user to enter all correct

Vehicle info

3. Sellers can search a mechanic (authorized person) in their

surroundings.

4. Mechanic’s comments increases reliability and chances of selling vehicle

5. The system will generate the message automatically and send to buyer if any buyer is waiting

Special requirement Seller registration is required

Technology and data

variation listInternet connection , HTTP, HTML, ASP and GSM

Frequency of occurrence Whenever any seller want to sale vehicle

Table: 4.2.9 Sale Vehicle (For Registered Users)




Use case name Buy Vehicle


Level User goal

Primary actor Buyers

Stake holder and their interestBuyers: The registered users

Interest : Want to buy the vehicle

Precondition User have to log in to buy vehicle

Success guarantee The buyers can buy vehicles


1. When online user select buy vehicle option

2. The system will show the vehicle info

3. Sellers will give rating to mechanic of their choice

4. The system will generate the message automatically and send to seller

Extension

1. When online user select buy vehicle option

2. The system will prompt show Vehicle info

3. Mechanic’s comments increases reliability and chances

of selling vehicle

4. The system will generate the message automatically and send to buyer if any buyer is waiting


Technology and data variation list Internet connection , HTTP, HTML, ASP and GSM

Frequency of occurrence When buyer want to buy vehicle

Table: 4.2.10 Buy Vehicle (Registered Users)




Use case name Forum Feedback


Level Sub Function

Primary actor All registered users

Stake holder and their interestRegistered users : all registered users

Interest :to put comments and feedback

Precondition All registered users required authentication

Success guarantee All registered users can put comments and feedback

Main success scenario1. User will log in

2. User will put comments and feedback

Extension

1. User may help each other to identify fake users.

2. User may inform each other about vehicle industry

updates.

3. User may help each other in resolving vehicle faults.


Technology and data variation list Internet connection , HTTP, HTML, ASP

Frequency of occurrence Whenever user give feedback on forum

Table: 4.2.11 Forum Feedback (For Registered Users)




Use case name Put Buy Request


Level User goal

Primary actor Buyer

Stake holder and their interestBuyer : all registered users

Interest :to put buy vehicle request


Success guarantee All registered users can put buy vehicle requests


1. User will log in

2. User will search to buy vehicle

3. User will put buy vehicle request if vehicle is available

4. User will be informed by automatic system generated

SMS / Email when the required vehicle will be available



Frequency of occurrence Whenever user give feedback on forum

Table: 4.2.12 Put Buy Request (For Registered Users)




Use case name Place Advertisements


Level Sub Function



Interest : To place advertisements


Success guarantee All registered users can place advertisements


1. User will log in

2. User will place advertisements

3. User will make payment

Extension1. User will place advertisements to sale vehicle

2. User can place any advertisements



Frequency of occurrence Whenever user want to place advertisements

Table: 4.2.13 Place Advertisements (For Registered Users)


Use case name Place Bids




Level Sub Function



Interest :to place bids

PreconditionAll registered users required authentication and bid registration fee

that is refundable if the bid fails

Success guarantee All registered users can place bids


1. Users will log in

2. Users will place bids

3. Users will pay bid fee that is refundable

Extension User may help each other to identify fake bids



Frequency of occurrence Whenever user want to place bids

Table: 4.2.14 Place Bids (For Registered Users)

4.3 Activity Diagram


Home Page

Authentication Registration

[Registered users] [Visitors]

[Invalid][Invalid]

[Valid] [Valid]

[Check Parameters][Check Parameters]

[Admin] [seller] [Buyer] [Mechanic]

Manage Ads Manage Bids

FinalizeBids

Send Bid Info(SMS/Email)

Sale Vehicle

Upload VehicleInformation

Buy Vehicle

AdvertiseVehicle Bid Vehicle

SaleNormally

Pay ForAdvertisement

inform User(SMS/ Email)

Browse choice(Vehicle)

View VehicleInfo

PutRequest

Comment VehicleCondition

Change Ads

Feedback

SearchMechanic


Table: 4.3.1 Activity Diagram

4.4 Domain Model Diagram



Fig. 4.4.1 System Domain Model

4.5 Sequence Diagrams

The system has following sequencing

4.5.1Searching Vehicle



Fig: 4.5.1 Sequence of Sequence of Searching Vehicle

4.5.2User Registration


search_request

page_rendered

search:page

get_search_page

Buyer

vehicle_not_found

>Browser

Database

view_vehicle_info get_vehicle_info

return_vehicle_infoinfo_rendered


Fig: 4.5.2 Sequence of User Registration

4.5.3View Vehicle History


Reg_request()

Return_form

submit()

>Browser

visitor

check _parameters() add_user()

Databaseregistration:

page

invalid _parameters

user_added()

user:thevisitor

get_reg_form

user_registered


Fig: 4.5.3 Sequence of View Bidding History

4.5.4 Admin Log In (Admin has super rights)


search_request(url)

page _rendered

search:page

get_search_page()

User>Browser

Database

view_bidding_history() get_bidding_details()

return_biding_detailshistory_rendered


Fig: 4.5.4 Sequence of Admin Log In

4.5.5 Managing Advertisements


login_request

Return_form

submit

>Browser

check _parametersmatch_password

>Login_page

invalid _parameters

AuthorizedUser user:theuser

password_matchedlogged_in

password_not_matched

Database


Fig: 4.5.5 Sequence of Managing Advertisements

4.5.6 Managing Bids


manage_ads

page _rendered

ads:adspage

get_ads_page

>Browser

post_ads

Database

save_ads_info

saved_ads_infoads_posted

Administrator

remove_ads

ads_removed


Fig: 4.5.6 Sequence of Managing Bids

4.5.7 Managing Forums


manage_bids

page _rendered

bids:page

get_bids_page

>Browser

finalize_bid

Database

save_bid_info

bid_info_savedbid_ends

Administrator

remove_biddelete_bid_info

send _SMS/Email

user:the buyer

delete_bid_info bid_removed

inform_seller & buyer

SMS/Email_sentinformed_seller & buyer


Fig: 4.5.7 Sequence of Managing Forums

4.5.8 User Feedbacks


manage_forum

page _rendered

forum:page

get_forum_page

>Browser

post_message

Database

save_message

message_savedmessage_posted

Administrator

remove_message

message_removed

delete_message

message_deleted


Fig: 4.5.8 Sequence of User Feedback

4.5.9 Vehicle Inspection (Mechanic’s Module)


feedback_request

page _rendered

forum:page

get_feedback_page

>Browser

post_message

Database

save_message

message_savedmessage_posted

Registered user

remove_message

message_removed

delete_message

message_deleted


Fig: 4.5.9 Sequence of Vehicle Inspection

4.5.10 Selling Vehicle


vehicle_comments

page_rendered

search:page

get_comments_page

Buyer>Browser

Database

post_comments save_comments

comments_saved posted_comments


Fig: 4.5.10 Sequence of Selling Vehicle

4.5.11 Buying Vehicle


sale_vehicle

page _rendered

vehicle_info:page

get_sale_page

Seller>Browser

user:the buyer

upload_vehicle_info

search_mechanic

inform_buyer (SMS/Email)

Database

save_vehicle_info

vehicle_info_saved


user:the mechanic

get_mechanic_info

return_mechanic_infomechanic_info_rendered


Fig: 4.5.11 Sequence of Buying Vehicle

4.5.12 Put Buy Request


buy_vehicle

page _rendered

vehicle_info:page

search_vehicle

Buyer>Browser user:the seller

view_vehicle_info

rate_mechanic

inform_seller (SMS/Email)

Database

get_vehicle_info

vehicle_info_returned

SystemGenerated

(automatic)

vehicle:the vehicle

check_parameters

store_mechanic_rating

rating_assigned


Fig: 4.5.12 Sequence of Put Buy Request

4.5.13 Placing Bid


search_vehicle

page_rendered

search:page

get_search_page

Buyer>Browser

Database

put_request save_request

request_saved posted_vehicle_request


Fig: 4.5.13 Sequence of Placing Bids

4.5.14 Placing Advertisements


bid_request

page _rendered

bids:bidspage

get_bids_page

User>Browser payment:pay

place_bid make_payment

Database

save_bid_info

saved_bid_infopayment_verifiedbid_placed

Refundableif bid fails


Fig: 4.5.14 Sequence of Placing Advertisements

4.6 Class Diagram


advertisement_request

page _rendered

ads:adspage

get_ads_page

User>Browser payment:pay

place_ads make_payment

Database

save_ads_info

saved_ads_infopayment_verifiedads_placed


Fig. 4.6.1 System Class Diagram


User

- ID : int- Email : String- LoginStatus : String

+ varifyLogin() : bool+ search()+ viewProfile()+ feedback()

Visitor

- ID : int- Name : String

+ search_vehicle()+ ViewHistory()

Seller/Buyer

- Name- Password : String- PhoneNo : int- CreditcardInfo :String

+ register()+ login()+ add_profile()+ update_Profile()+ buy()+ sale()+ bid()

Mechanic

- Name : String- Password : String- PhoneNo : int- Location : string- Charges : int

+ login()+ checkVehicle()+ comments()

Bid

- BidID : int- BidAmount : int- OwnerID : int- Date : Date- Time : Date/Time- BestBid : int

+ place_bid()+ view_bid()+ start_bid()+ cancel_bid()+ finalize_bid()+ close_bid()+ makePayment()

All Classes haveCRUD operations

likeInsert,Update,

Delete etc

search

check

sell/buy

1

11

0..*

1..*

*

*

*

*

Forum

- Subject : String- Postedby : String- PostedDate : Date

+ forum_feedback()+ post_Comment()+ del_Comment()

Admin

- adminName : String- Password : String

+ login()+ manageBid()+ manageForum()+ manageProfile()+ manageVehicle()

Vehicle

- Vehicle_ID : int- Image- Model : String- EngineNo : int- ChassisNo : int- Registration : String- Color : String- Price : int

+ search()+ vehicle_Info()+ advertise()+ view()+ mechanic_comment()

1..*

View

man

age

0..*

manage

1..*

1..*

1..*

1..*

* 1..*

History

- History(Sale)- History(Purchase)- History(Bid)

+ View_History()+ Vehicle_history()+ bid_history()

*

manage

1..*

0..*

1

1

Advertisement

- Ad_ID : int- Posted_date : Date

+ place_add()+ post_add()+ remove_add()

1..* *Place


4.7 Entity Relationship Diagram

Fig. 4.7.1 System RE Diagram



4.8 Deployment Diagram

Fig. 4.8.1 System Deployment Diagram

4.9 Operational Contracts


User (Admin, Seller, Buyer, Mechanic)

POP3, SMTP and HTTP

HTTP

Web Browser

User PC

Windows OS

I I S

Server (Mainframe)

Web Server

Wi n d o w sSe r v er

SMS Gateway

SQLd a t a b a s e

Mi c r o s o f tSQL s er v e r

2005

Database Server

ADO. Net

mo b i l e

Ema i lSe r v e r

G SM


4.9.1 User Registration

Operation: addUser ()

Cross References: Use Cases: Registration.

Pre-Conditions: User will request for the

registration.

Post-Conditions:

Registration instance reg was created.

reg was associated with the database.

reg can add the values into the

database.

reg can return the message.

4.9.2 Search Vehicle

Operation: searchingVehicle ()

Cross References: Use Cases: Searching

Pre-Conditions: User will request for the vehicle

Search Vehicle.

Post-Conditions:

search was associated with the database.

search can fetch the values from the

database.

search can return the values.

4.9.3 Selling Vehicle

Operation: saleVehicle()

Cross References: Use Cases: Sale.

Pre-Conditions: User will request for the Sale

Vehicle.

Post-Conditions:

sale was associated with the database.

sale can add the values into the database.

sale can return the message.



4.9.4 Buying Vehicle

Operation: buyVehicle()

Cross References: Use Cases: Buy.

Pre-Conditions: User will request for the Buy

Vehicle.

Post-Conditions:

buy was associated with the database.

buy can fetch the values into the

database.

buy can return the message.

4.9.5 Sending Email/SMS

Operation: sendEMail()

Cross References: Use Cases:SendEMail.

Pre-Conditions: User will request for the Send

EMail.

Post-Conditions:

SendEMail instance sendm was created.

sendm was associated with the database.

sendm can add the values into the

database.

Server can send the message/mail.

4.9.6 Put Buy Request

Operation: putRequest()

Cross References: Use Cases: Put Buy Request.

Pre-Conditions: User will request for the Put Buy

Request.

Post-Conditions:

request was associated with the database.

request can add the values into the

database.



request can return the message.

4.9.7 Placing Bid

Operation: vehicleBidding()

Cross References: Use Cases: Place Bid.

Pre-Conditions: User will request for the Place Bid.

Post-Conditions:

bid was associated with the database.

bid can add the values into the database.

bid can return the message.

4.9.8 Place Advertisement

Operation: placeAdvertisement()

Cross References: Use Cases: Place Ads.

Pre-Conditions: User will request for the Place Ads.

Post-Conditions:

ads was associated with the database.

ads can add the values into the

database.

ads can return the message.

4.9.9 Vehicle Inspection

Operation: inspectVehicle ()

Cross References: Use Cases: Vehicle Inspection.

Pre-Conditions: User will request for the Vehicle

Inspection.

Post-Conditions:

incpct was associated with the database.

incpct can add the values into the database.

incpct can return the message.



Chapter 5

IMPLEMENTATION

This section includes explanation of different models of the system.

5.1 User Registration

Registration is provided in some cases e.g. when user wants sale, buy, place bid, place

ad etc. User can easily register through Website by filling up a simple registration

form. Before inserting the values into the database Online Verification of Email

address and password will be made to identify the fake Email addresses.

5.2 Selling/ Buying a Vehicle

To sale the vehicle user have to provide detailed information of the

vehicle as well as photos. Whenever any user want to buy the

vehicle seller will be informed by Email/SMS. On the other hand

buyer will also be informed about seller through Email/SMS.

5.3 Put Request

If users can’t find vehicle of their choice they can put request of a

particular choice. Whenever the desired vehicle will be available

they will be informed by SMS/Email.

5.4 Vehicle Inspection

Users can get inspection of their vehicles by authorized vehicle

mechanic. It’s optional for the sake of reliability & customer

satisfaction. It also increases the sale chances.

5.5 Place Bid



The system also provides the facility of bidding. Users can place

bids. Bids will be offline

5.6 Place Advertisements

Users can place advertisements on the site. Multiple types of

advertisements can be placed such as vehicle for sale, vehicle

required, general ads etc

5.6 Sending Email/SMS

This module have is not directly accessible. This will be used by

system automatically when required

5.7 Web component

Web component is implemented in 3 layers. We used three layer

architecture to achieve effective design that provides (when

compared to the two layer) increased performance, flexibility,

maintainability, reusability, and scalability, while hiding the

complexity of data processing from the user.

• Presentation Layer

• Business Logic Layer

• Data Access Layer

5.7.1Presentation Layer

This is the top most level of the application. The presentation layer

displays information related to such services as displaying

information user interaction wit the system taking inputs from the

user and displaying outputs to the user.

5.7.2Business Logic Layer



It controls applications functionality by performing detailed

processing. The Validations, Inter mediate Processing and requests

send to database for processing comes under Business Logic layer.

It takes inputs from presentation layer apply interpret it apply any

necessary business logic and then call data access layers methods

for further processing it takes the results from data access layer

again and pass it to the presentation layer for displaying g it to the

user.

5.7.3Data Access Layer

(DAL) is a layer of a computer program which provides simplified

access to data stored in persistent storage of some kind, such as an

entity-relational database.

DAL might return a reference to an object (in terms of object-

oriented programming) complete with its attributes instead of a row

of fields from a database table. This allows the client (or user)

modules to be created with a higher level of abstraction. This kind of

model could be implemented by creating a class of data access

methods that directly reference a corresponding set of database

stored procedures.



Chapter 6

SOFTWARE TESTING

6.1 TEST PLAN

A test plan documents the strategy that will be used to verify and

ensure that a product or system meets its design specifications and

other requirements.

6.1.1 INTRODUCTION

This document is a high-level overview defining our testing strategy

for the SayVoice System. Its objective is to communicate project-

wide quality standards and procedures. The primary focus of this

plan is to ensure that the SayVoice System will provide better and

secure performance to the user. The project will have three levels of

testing, Unit, System/Integration and Acceptance Testing. We will

utilize testing criteria under the white box and system-testing

paradigm. This paradigm will include, but is not limited to, the

testing criteria, methods, and test cases of the overall design.

Throughout the testing process we will be applying the test

documentation specifications described in the IEEE Standard 829-

1983 for Software Test Documentation.

TEST OBJECTIVES

The main objective of our test plan is to find and report as many

errors and bugs as possible to improve the performance of our

System. SayVoice System has four main components.

SMS to Email conversion, Email to SMS conversion, WEB to mobile

chat and text to voice conversion. Two components (Web to Mobile

chat and Text to Voice converter) has Graphical user interface



6.2 Testing Process

6.2.1 Organize Project:

Organize your project for test according to the following criteria.

6.2.1.1 Schedule

The following tentative schedule will hopefully meet:

Test design (this document) is expected to be completed by 18-07-

2011

Test execution is expected to last no more than two weeks and to

start immediately after the test plans have been approved.

Producing the Test Incident/Summary report is expected to be

completed within 2 days of completing the test execution phase

6.2.1.2 Test Approach/Strategy

We will use unit, integration, system, recovery, security and

acceptance testing for our SayVoice System. Each Test Case will be

prioritized as High, Medium and Low Priority and then scheduled

accordingly. Exceptions to this general rule might include instances

where:

• A large number of low priority test cases can be executed

using a small amount of resources

• A lower priority test is a pre-requisite of another higher

priority test e.g. an expensive and high priority usability test

might necessitate many of the inexpensive low priority

navigational tests to have passed

• Due to the lack of comprehensive requirements, navigational

and functional tests may be scheduled first, so as to allow the

testers the opportunity to gain familiarity with the Web site

(thereby also allowing them to developing pseudo

requirements).



Basic metrics will be kept for test effort (i.e. hours), test cases

executed, and incidents. Due to the lack of available tools and time,

no attempt will be made to collect more sophisticated metrics such

as code coverage. The following type of testing will be done:

6.3 Unit Testing:

The goal of unit testing is to isolate each part of the program and

show that the individual parts are correct. Unit testing provides a

strict, written contract that the piece of code must satisfy.

As a result, it affords several benefits.

Unit testing allows the programmer to refractor code at a later date,

and make sure the module still works correctly (i.e. regression

testing). This provides the benefit of encouraging a programmer to

make changes to the code since it is easy for the programmer to

check if the piece is still working properly. Unit testing will be done

for the following units:

• User Registration.

The testing of this unit will ensure that whether the user has

been registered successfully or not.

• Login

The purpose of this unit testing is to ensure that the user

should never buy, sale, place bid without signing in.

• Update Account

The testing of this unit will ensure that whether the user

account has been updated successfully or not.

• Sale Vehicle

The testing of this unit will ensure that whether the vehicle

information has been uploaded successfully or not.

• Put Buy Request



The testing of this unit will ensure that whether the request

has been put successfully or not

• Place Bid

The testing of this unit will ensure that whether the bid has

been placed successfully or not.

• Place Advertisements

The testing of this unit will ensure that either the

Advertisements has been placed successfully or failed.

• Bidding Price

The testing of this unit will ensure that new bid price should

be greater than last price.

• Finalize Bid

The testing of this unit will ensure that the bid should be

finalized and ended.

• Inform to User

The testing of this unit will ensure that either the user has

been informed successfully or not.

• Email sending link

The testing of this unit will ensure that link of user has been

formed successfully or not.

• Sending Email

The testing of this unit will ensure that either the Email has

been sent successfully or not.



• Send SMS

The testing of this unit will ensure that either the SMS has

been sent successfully or not.

• Create Forum Topic

The testing of this unit will ensure that either the new topic

has been posted successfully or not.

• Logout

The testing of this unit will ensure whether user easily logout

from his account or not.

6.4 Integration testing:

Integration testing is the phase in software testing in which

individual software modules are combined and tested as a group. It

occurs after unit testing and before system testing. The tests are

conducted to ensure that the components are integrated to perform

together. All modules are integrated by an incremental approach,

and integration testing of the system is performed follows:

• Integrate account creation module and test that the software

perform login operation accurately and connected properly to

database.



• Integrate updating module and test that the software

performs the updating and data is successfully stored into

database.

• Web to SMS chat is integrated and tests that message is

properly deliver to the user.

• Integrate extracting Email from pop3 server, summary

generation, converting into SMS and sending SMS to test that

mail is successfully send to the user.

• Integrate the text to voice component to test that required

voice is generated or not.

6.5 System testing:

System testing involves the set of tests that the entire system

performs according to specification:

• Functionality Testing

In testing the functionality of the website following should

be tested

Links

1) Internal Links

2) External Links

3) Broken links



Forms

1) Field Validation

2) Error message for wrong inputs

3) Optional and mandatory fields

Database

Testing will be done on database integrity.

• Performance Testing

Performance testing can be applied to understand the web site’s

scalability, or to benchmark the performance in the environment

of third party products such as servers and middleware for

potential purchase.

• Connection Speed

Tested over various networks like Dial Up, ISDN etc

Load:

i. what is the no. of users per time?

ii. Check for peak loads and how system behaves

iii. Large amount of

Documents

Online Vehicle Showroom · PIR MEHR ALI SHAH ARID AGRICULTURE UNIVERSITY RAWALPINDI JULY, 2011. ONLINE VEHICLE SHOWROOM Dedicated to our beloved parents and to all those, whose prayers