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
