Vending Machine Through Mobile

(A BLUE TOOTH BASED APPLICATION)

 GOAL OF OUR SYSTEM

• User can use a cell phone to select the product to be

purchased from among a list of products and buy them
through telemetry.

• OUR SYSTEM is J2ME based Bluetooth mobile

application which when installed in a Java enabled
mobile phone lets a user make a purchase of an item
through the mobile phone.
 Problems with the current scenario:

• Coin acceptors often jam up, especially if a bill

or other foreign object is inserted into the coin
slot.
• Moreover these vending machines are not smart
enough to give you change for the products you
have bought.
• Also these vending machines need more
manual interaction which is not always
recommended.
• Also people are looking for innovative solutions
from the vendors to their buying problems.
 I NG
NN
A
PL
 Proposed Solution
• The scheme relies on a radio frequency transmission
medium, which guarantees fully bi-directional
• This scheme has opened door for the vendors to adopt a
new alternative paying scheme that will help them to
attract the customers.
• This project also focuses on developing an alternative
scheme for payment through credit cards.
 MODULES

There are four modules present in the system.

They are:
• Vending Machine Module
• Purchase Request Module
• Billing Module
• Payment module
– Talk time.
– Credit card Payment
 Vending Machine Module

Functionality:
• Show List
The lists of the categories available in the repository The
products in the selected category are also displayed.
• Update Inventory
Whenever products are purchased, the amount of
products sold will be deducted from the inventory levels.
When the inventory level of a product goes down the
minimum requirement, product name will be deleted from
the available list of products. It has to be updated again
by the administrator whenever the product is added to
the inventory.
 Purchase Request Module

• Functionality:
• Viewing the list of categories of products.
• To make a request for buying a product of
desired quantity.
 Billing Module
• Make Bill
A bill is generated for the purchased
product.
• Transaction Log
Records the list of transactions performed
 Payment module
• Credit card Payment
If the payment is through the credit card,
then the card details will be send to the
bank and the amount will be collected
later.
• Talk time payment
If the payment is through service provider
then the amount of purchase will be
deducted from the user’s talk time.
 SOFTWARE REQUIREMENTS
• SERVER
• Operating system ---- Windows XP
• Server Side Prog ---- java Servlets
• Web server ---- Apache tomcat 5.5
• Database ---- Oracle 8.0
• Client
• Operating system ---- Palm OS
• Blue Tooth Mobile ---- J2ME Wireless Toolkit
 HARDWARE REQUIREMENTS

• Server
• PIII or higher processors
• 256 MB RAM
• 20 GB Hard Disk

• Client
• Bluetooth enabled mobile phone is sufficient
 SI S
LY
N A
A
FUNCTIONAL REQUIREMENTS
MAINTAIN INVENTORY UPDATE INVENTORY

VIEW REPOSITORY

SELECTING CATEGORY

SELECTING PRODUCTS

BILLING
VENDING
MACHINE
USER
PRODUCT INFO

SIM CARD PAYMENT SERVICE VALIDATING SIM CARD

PROVIDER

ACCOUNT PAYMENT CREDIT CARD VALIDATING ACCOUNT

 The actors identified in this system are:
• User.
• vending machine.
• Service Provider
• TTP
The use cases that are identified in this
system are
1. View repository
2. Select category
3. Select product.
4. Billing system
5. Sim card payment.
6. Credit card payment
MAIN USE CASE DIAGRAM
VIEW REPOSIT ORY

<<include>>

SELECT CAT EGORY

<<include>>
MAINT AIN REPOSIT ORY

USER SELECT PRODUCT S

PRODUCT INFOMATION

VENDING
UPDATE INVENTORY MACHINE

<<include>>
PURCHASE

RECORD T RANSACT ION

<<extend>>
ALERT S

BILLING SYST EM
<<include>>

<<include>>

SIM CARDVALIDAT ION service

SIMCARD PAYMENT
PAYMENT M ODE provider

<<include>>

ACCOUNT PAYMENT ACCOUNT VALIDAT ION CREDIT

CARD
 SUB USE-CASE FOR PURCHASE

Select Product

<<include>>

<<include>>

Select payment Mode Maintain Repository Vending

Purchase <<include>> Machinr
User
(from Logical View)

buy product
 SUB USE-CASE FOR VIEW REPOSITORY

getCategory
<<include>>

<<include>>

User View Repository selectCategory Repository Vending machine

<<include>>
(from Use Case View)

getProducts
 ACTIVITY DIAGRAMS
• Activity diagrams are special case of the
state machine
• Activity diagrams provide a view of flows
of what is going inside the use cases or
among several classes
 Ve nding M ac hine
Activity diagram Us er Serv ic e Pr ov ider TTP

Connect

Get
Categories

Select
category

Get
Products

Select
Product

[ Yes ]
Buy ?
[ Yes ]
Display Bill
Details [ No ]
W rong
Information ?

[ Credit Card ]
Payment
mode ?
Enter Pin Enter Card
[ Bank ]
number details

[ Yes ]
Valid Valid
account? details?
[ Yes ]
[ No ]

Receipt [ No ]

Record the Display

Transaction Information

Collect
the Item
 SEQUENCE DIAGRAMS

• Provides graphical view that shows object

interaction in time based sequence
• These diagrams establishes the roles of
the objects and provide essential
information to determine class
responsibilities
UPDATE INVENTORY

: view inventory : update inventory : VENDING

: USER MACHINE

1: start interface()

2: select products()

3: get product id()

4: get product quantity()

5: check details()

6: forward details for validation()

7: validate details()
 PURCHASE
: USER : purchase UI : PURCHASE
: view inventory : VENDING
MACHINE

1: start interface()

2: select category()

3: select product()
4: select payment m ode()

5: forward details()

6: forward details()

7: check validations()

8: validate()

9: forward authentication details()

10: verify details ()

11: proces s the request()

 CREDIT CARD
: USER : VENDING : credit card gui : credit card system
MACHINE

1: start interface()

2: get credit card no()

3: get pin no()

4: forward details()

5: check for authentication()

6: forward results()

7: verify and process requests()

 SIM CARD

: USER : serviceprovider UI : VENDING : SERVICE

MACHINE PROVIDE

1: start interface()

2: get simcard no()

3: get pin no()

4: forward details()

5: forward details for authentication()

6: authenticate details()

7: forward results()

8: verify and process request()

 CLASS DIAGRAM
• Class diagrams are created to provide a
picture or view of some or all of the
classes in the model.
• The main class diagram in the logical view
of the model is typically a picture of the
packages in the system
 CLASS DIAGRAM
<<entity class>>
service provider
<<boundary class>>
simno : Integer
bill balance : Double
bill amount : Double
interacts
pin : Integer
bill date : Date 1..n
pay mode : String 1 start interface()
provide details()
make bill()
pay bill() interacts
1
record transaction() << entity class>>
1 ttp
1..n card no : String
expiry date : Date
coordinates
holder name : String
credit : Double

check account()
1..n
make transaction()
<<control class>>
vending machine

get credit card no() <<boundary class>>

get pin no() category
forward results() cat_id : String views
process and verify request() 1 name : String 1..n <<entity class>>
updates 1..n user

selects process the request()

1..n <<boundary class>> 1..n
product
0..n
name : String
code : String
FUNCTIONAL ARCHITECTURE
Mobile with vending machine
Vending machine checks
database
Checks bank details
Checks service provider
SYSTEM ARCHITECTURE
ACTI

CNAME

BALANCE

SERVICE
PROVIDER PIN CATEGRO PNAME
Y

To CNAME
SIMN
O
PRODUC
Vie
T MNAM
ws E

CTYPE

COST

INTER EXPIRY
BUYS DATE
ACTS CARD
TYPE

CARDNO

TID CVVNO
CName

TMODE
BILLING
SYSTEM
MNAME CREDITCARD

BAMOUNT IN
AC TE
TS R
PNAM
TDATE E
 List of data base tables identified
• Category
• Products
• Measurement
• Transaction
• Service provider
• Visa
• Transaction processing(ttp)
• vodaphone
 Category table

cname Varchar2(20) primarykey

Product table

pname Varchar2(20) primarykey

cname Varchar2(20) Foreign key

Cname represents customer name

Pname represents product name
 Measurement table
pname Varchar2(20) Foreign key

mname Varchar2(20) Primary key

quantity Number(3) Not null

cost Number(7,2) Not null

 Transaction table
Tid Number(5) Primary key
Tmode Char(1) not NULL
BAmount Number(7,2) not NULL

Tdate Date not NULL

Pname Varchar2(20) Foreign key
Mname Varchar2(10) Foreign key
 Service provider
Name Varchar2(20) Primary key
 Vodaphone

Cname Varchar2(20) Foreign key

Sim no Number(10) Primary key

Pin Number(6) Not null

Balance Number(6,2) Not null

activation Char(2) Not null

 TRANSACTION PROCESSING
NAME VARCHAR2(20) PRIMARY KEY
 VISA
CNAME VARCHAR2(20) FOREIGN
KEY
CARDNO NUMBER(16) PRIMARY
KEY
EXPIRY DATE not NULL
DATE
CREDIT NUMBER(7,2) not NULL
CARD
CVV NO NUMBER(10) not NULL
Interface design
Welcome screen
categories
List of products
Puchase the products
Pay mode
Account details by sim card
Account details by using credit card
Receipt form
 NG
T I
S
TE
 Authentication of user with Service Provider

Test Case: Authentication of user

Test Description: With the cell phone number and pin as the input, validate the user.

Pre Conditions: User should have a Valid Account with Service Provider

Action Performed: 1) Correct details entered.

2) Wrong details entered.

Expected Results: 1) Connected to server and product is delivered.

2) Not Connected to server and Repurchase.

Conditions Verified: yes

Result: Success
 Product Available

Test Case: Product Available

Test Description: To verify the Product of Sufficient quantity is available

Pre Conditions: Database Connectivity

Action Performed: 1) Product Available.

2) Product Not Available

Expected Results: 1) Ask for Payment Details.

2) Alert the User.

Conditions Verified: yes

Result: Success
 User Validation

Test Case: User Validation

Test Description: With the credit card and cvv no. as the input, validate the user.

Pre Conditions: User should have a Valid Account with bank.

Action Performed: 1) Correct details entered.

2) Wrong details entered.

Expected Results: 1) Connected to server and product is delivered.

2) Not Connected to server and Repurchase.

Conditions Verified: yes

Result: Success
 CONCLUSION
The following benefits can be observed with this system:
• Convenience and flexibility in the mobile payment
scheme.
• A reliable scheme with completely no manual interaction.
• Also the reports generated by the system can be helpful
in tracking the customer needs and maintaining the
correct inventory levels.
Moreover by implementing this system we gained a clear
understanding of project life cycle and the Bluetooth
technology.
 LIMITATIONS
• This project of course has a broad range
but was implemented only for the vending
machine scenario.
• Also this project, as it is implemented
using Bluetooth technology, was
constrained to the distance of operation.
 FUTURE ENHANCEMENTS
• This project can further be extended to a wide
range of products and categories.
• An example of the future enhancement is an
ATM machine where a user can make a
transaction through any bank card at a single
place.
• Implementation of project in Real Time
Environment
• Also it is possible to bring a variety of customers
under one roof with the help of this system.
 a n Q
T h