Vending Machine Sreevidhya@Students

8/8/2019 Vending Machine Sreevidhya@Students

http://slidepdf.com/reader/full/vending-machine-sreevidhyastudents 1/61

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 billor other foreign object is inserted into the coinslot.

Moreover these vending machines are not smartenough to give you change for the products youhave bought.

Also these vending machines need moremanual interaction which is not always

recommended. Also people are looking for innovative solutions

from the vendors to their buying problems.





Proposed Solution

The scheme relies on a radio frequency transmissionmedium, which guarantees fully bi-directional

This scheme has opened door for the vendors to adopt anew alternative paying scheme that will help them toattract the customers.

This project also focuses on developing an alternativescheme 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 fromthe available list of products. It has to be updated againby the administrator whenever the product is added tothe 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 thebank and the amount will be collectedlater.

Talk time payment

If the payment is through service provider then the amount of purchase will bededucted 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





FUNCTIONAL REQUIREMENTS

MAINTAIN INVENTORY UPDATE INVENTORY

VALIDATING SIM CARD

VENDING MACHINE

SERVICEPROVIDER

VIEW REPOSITORY

PRODUC T INFO

SELECTING PRODUCTS

SELECTING CATEGORY

BILLING

SIM CARD PAYMENT

USER

ACCOUNT PAYMENT VALIDATING ACCOUNTCREDIT CARD



The actors identified in this system are:

User.

vending machine. Service Provider

TTP



The use cases that are identified in thissystem 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

¡

¢

£

¤

¥ ¡

¦ ¢

§ £

¤ ̈

¡

¢

ACC©

UN

A

ID A

I©

NC R E D I

CARD

RE C©

RD

R A N S A C

I©

N

S I M C A R D A

M E N

ACC©

UN

A

M E N

<< !

>>

A

M E N

M©

DE

S E

E C

CA

EGOR

S E

E C

RODU C

S

<< !

>>

UR C"

ASE

U S E R

M A I N

AIN RE OS I

OR

IE

#

RE O

S I

OR

<< ! >>

RODU C

IN$

OM A

ION

U

D A

E IN

E N

OR

<< !

>>

% I

ING S

S

E M

<< !

>>

<<!

x&

! >>

A E R

S

ENDING

M A C"

IN E

S I M C A R D

A ID A

ION

<< !

>>



SUB USE-CASE FOR PURCHASE

S P

S R

UP



SUB USE-CASE FOR VIEW REPOSITORY

User

(from Use Case View)

View Repository Vending machine

getCategory

<<include>>

selectCategory

<<include>>

getProducts

<<include>>

Repository



ACTIVITY DIAGRAMS

Activity diagrams are special case of the

state machine

Activity diagrams provide a view of flowsof what is going inside the use cases or

among several classes



Activity diagram

G'

t(

a t'

g)

r i' 0

G'

t1 r

)

d 2 c t0

3 i0

4 5 a y 6 i 5 5 3

'

t a i 5

0

7

'

c'

i 4 t

7

'

c)

r d t 8

'

9

r a @

0

a c t i)

@

(

)

@ @

'

c t

A

'

5

'

c tc a t

'

g)

r y

A

'

5

'

c t1 r

)

d 2 c t

6 2 y ?[

B

' 0

]

C

r )

@ gD @

E

)

r m a t i)

@ ?

1 a y m'

@ tm

)

d'

?

3 i0

4 5 a yD @

E

)

r m a t i)

@

(

)

5 5

'

c tt 8

'

D t'

m

F @ t'

r 1 i @ @ 2 m G

'

r [ 6 a @ H ]

I

a 5 i da c c

)

2 @ t ?

F @ t'

r (

a r dd

'

t a i 5

0

[(

r '

d i t(

a r d ]

I

a 5 i dd

'

t a i 5

0

?

[B

' 0

]

[B

' 0

]

[ P

)

]

[ P

)

]

[B

' 0

]

[ P

)

]

TTPService Provider User Vending Machine



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





PURCHASEQ

U S E R Q R S T

U

V

W X Y

U ̀

Q P U R C H A S EQ

a

E b c ` b d

e ACH

` b E

Q

f

g

Y h

g i

f Y

i

p

q

T

r

s Q

X

p

W

T

p

g i

p

Y

T

t

W U Y

u v

w

Q

X Y

x

Y U

p

U W

p

Y y q

T

r

u v

Q

X Y

x

Y U

p

R T

q

S

U

p

u v

Q

X Y

x

Y U

p

R

W r

Y

i

p

q

Y

u v

Q

t

q

T

h W

T

Y

p

W

g x

X

u v

Q

t

q

T

h W

T

Y

p

W

g x

X

u v

Q

U

V

Y U

f W

x g

W

p

g

q

i

X

u v

Q

f W

x g

W

p

Y

u v

9Q

t

q

T

h W

T

W

S

p

V

Y

i

p

g

U W

p

g

q

i

Y

p

W

g x

X

u v

s

Q

f Y

T g

t

r

Y

p

W

g x

X

u v

s s Q R T

q U Y X X

p

V

Y

T

Y

S

Y X

p

u v



CREDIT CARD

E R

E

D I

A C I E

j k j

l

m

n

o

j

m

m

z

j

{

|

}

n

|

~

j

n z

j

k

j j

n

j

j



SIM CARD

S R

D I M A C I

I S R

IC R

ID



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

ª « ¬ - ® ̄ I- ° ± ² ± ³

´ µ ¶ µ - · ±

̄D

® ¸ ´ ¶ ±

¹ « - ̄ I- ° ± ² ± ³

ª ° µ ³ °

« - ° ± ³

º

µ · ± » ¼

¹ ³ ®

½

« ¾ ± ¾ ± ° µ « ¶ ª » ¼

¿ ¿ ± - ° « ° À · ¶ µ ª ª Á Á

· µ ³ ¾ - ® ̄ S ° ³ « - ²

±

Â

¹ « ³ À

¾ µ ° ±

̄D

µ ° ±

Ã ® ¶ ¾ ± ³

- µ ¬ ±

̄S

° ³ « - ²

· ³ ± ¾ « °

̄D

® ¸ ´ ¶ ±

· Ã ± · Ä

µ · · ® ¸ - ° » ¼

¬ µ Ä ±

° ³ µ - ª µ · ° « ® - » ¼

¿ ¿ ± - ° « ° À · ¶ µ ª ª Á Á

· µ °

_ « ¾

̄

S° ³ « - ²

- µ ¬ ±

̄S

° ³ « - ²

¿ ¿ ´ ® ¸ - ¾ µ ³ À

· ¶ µ ª ª Á Á

¹ ³ ® · ± ª ª

° Ã ±

³ ± Å ¸ ± ª ° » ¼

¿ ¿ ± - ° « ° À

· ¶ µ ª ª Á Á

Æ Ç Ç -

Æ Ç Ç -

Æ Ç Ç -

Æ Ç Ç -

views

´ « ¶ ¶

µ ¬ ® ¸ - °

̄D

® ¸ ´ ¶ ±

´ « ¶ ¶

¾ µ ° ±

̄D

µ ° ±

¹ µ À ¬ ® ¾ ± ̄ S ° ³ « - ²

¬ µ Ä ±

´ « ¶ ¶ » ¼

¹ µ À

´ « ¶ ¶ » ¼

³ ± · ® ³ ¾

° ³ µ - ª µ · ° « ® - » ¼

¿ ¿ ´ ® ¸ - ¾ µ ³ À

· ¶ µ ª ª Á Á

Æ Ç Ç -

Æ

Æ Ç Ç -

Æ

interacts

Æ Ç Ç -

Æ

Æ Ç Ç -

Æ

interacts

- µ ¬ ±

̄S

° ³ « - ²

· ® ¾ ±

̄S

° ³ « - ²

¿ ¿ ´ ® ¸ - ¾ µ ³ À

· ¶ µ ª ª Á Á

È Ç Ç -

Æ Ç Ç -

È Ç Ç -

Æ Ç Ç -

selects

² ± °

· ³ ± ¾ « °

· µ ³ ¾

- ® » ¼

² ± °

¹ « -

- ® » ¼

º

® ³

É

µ ³ ¾ ³ ± ª ¸ ¶ ° ª » ¼

¹ ³ ® · ± ª ª

µ - ¾

½

± ³ «

º

À

³ ± Å ¸ ± ª ° » ¼

¿ ¿ · ® - ° ³ ® ¶

· ¶ µ ª ª Á Á

Æ Ç Ç -

Æ

Æ Ç Ç -

Æ

coordinates

Æ Ç Ç -

Æ

Æ Ç Ç -

Æ

updates



FUNCTIONAL ARCHITECTURE



Mobile with vending machine



Vending machine checks

database



Checks bank details



Checks service provider



S YSTEM ARCHITECTURE

ACTI



BALANCE

CNAME

CNAME

PNAME

BILLING

S YSTEM

TID

TMOD

E

BAMOUNT

TDATE

PNAME

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



List of data base tables identified

Category

Products

Measurement

Transaction

Service provider

Visa

Transaction processing(ttp)

vodaphone



cname Varchar2(20) primarykey

pname Varchar2(20) primarykey

cname Varchar2(20) Foreign key

Product table

Category table

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( ,2) Not null



Transaction table

Tid Number(5) Primary key

Tmode Char(1) not NULL

BAmount Number( ,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

DATE not NULL

CREDITCARD NUMBER( ,2) not NULL

CVV NO NUMBER(10) not NULL



Interface design



Welcome screen



categories



List of products





Pay mode



Account details by sim card



Account details by using credit card



Receipt form





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.


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.


Result: Success



CONCLUSION

The following benefits can be observed with this system:

Convenience and fle ibility in the mobile paymentscheme.

A reliable scheme with completely no manual interaction.

Also the reports generated by the system can be helpfulin tracking the customer needs and maintaining thecorrect inventory levels.

Moreover by implementing this system we gained a clear

understanding of project life cycle and the Bluetoothtechnology.



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.





Documents

Vending Machine Sreevidhya@Students