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.

PLANNING

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

ANALYSIS

FUNCTIONAL REQUIREMENTS

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

SUB USE-CASE FOR PURCHASE

SUB USE-CASE FOR VIEW REPOSITORY

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

Activity diagram

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

PURCHASE

CREDIT CARD

SIM CARD

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

FUNCTIONAL ARCHITECTURE

Mobile with vending machine

Vending machine checks database

Checks bank details

Checks service provider

SYSTEM ARCHITECTURE

BALANCE CNAME PNAME BILLING SYSTEM TID TMOD E BAMOUNT TDATE PNAM E CREDITCARD CVVNO CName CARDNO CARD TYPE EXPIRY DATE SERVICE PROVIDER To MNAME SIMN O PIN ACTI CTYPE MNAM E INTER ACTS PRODUC T COST BUYS Vie ws CATEGRO Y INTER ACTS

List of data base tables identified Category Products Measurement Transaction Service provider Visa Transaction processing(ttp) vodaphone

cnameVarchar2(20)primarykey pnameVarchar2(20)primarykey cnameVarchar2(20)Foreign key Product table Category table Cname represents customer name Pname represents product name

Measurement table pnameVarchar2(20)Foreign key mnameVarchar2(20)Primary key quantityNumber(3)Not null costNumber(7,2)Not null

Transaction table TidNumber(5)Primary key TmodeChar(1)not NULL BAmountNumber(7,2)not NULL TdateDatenot NULL PnameVarchar2(20)Foreign key MnameVarchar2(10)Foreign key

Service provider NameVarchar2(20)Primary key

Vodaphone CnameVarchar2(20)Foreign key Sim noNumber(10)Primary key PinNumber(6) Not null BalanceNumber(6,2)Not null activationChar(2)Not null

TRANSACTION PROCESSING NAMEVARCHAR2(20)PRIMARY KEY

VISA CNAMEVARCHAR2(20)FOREIGN KEY CARDNONUMBER(16)PRIMARY KEY EXPIRY DATE DATEnot NULL CREDIT CARD NUMBER(7,2)not NULL CVV NONUMBER(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

TESTING

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.

ThanQ