CS2103 Software Engineering Project

8/4/2019 CS2103 Software Engineering Project

1/23

CS2103 Software

Engineering Project

Vending Machine

Deliverable II

Team 5

AHMED SHAFEEQ BIN MOHD SHARIFF U080022Y [email protected]

CHUA KIEN CHUAN U087140B [email protected]

SOH YUAN CHIN U087201B [email protected]

TAN YAN HAO U087137L [email protected]


2/23

CS2103 Software Engineering Project

Chapter:RevisedUseCase

2

Table of Contents

Revised Use Case ................................ ................................ ................................ ................................ ........... 3

Revised Domain Model ................................ ................................ ................................ ................................ .. 4

Project Scope (Updates from Deliverable I) ................................ ................................ ................................ .... 5

Must Have ................................ ................................ ................................ ................................ ................. 5

Constraints................................ ................................ ................................ ................................ ................. 5

Diagram to Illustrate Sub-Systems ................................ ................................ ................................ .................. 6

Class Diagrams ................................ ................................ ................................ ................................ ............... 8

Interaction Diagrams................................ ................................ ................................ ................................ .... 11

State Charts ................................ ................................ ................................ ................................ ................. 12

Test Plan and Test Cases ................................ ................................ ................................ .............................. 14

Test Items Table ................................ ................................ ................................ ................................ ....... 14

Approach ................................ ................................ ................................ ................................ ................. 16

Item Pass/Fail Criteria ................................ ................................ ................................ .............................. 16

Testing Tasks ................................ ................................ ................................ ................................ ............ 17

Design Considerations ................................ ................................ ................................ ................................ .. 18

General Design ................................ ................................ ................................ ................................ ......... 18

Simulation ................................ ................................ ................................ ................................ ............ 18

Application Layer................................ ................................ ................................ ................................ .. 18

GUI Design ................................ ................................ ................................ ................................ ........... 21


3/23


Chapter:RevisedUseCase

3

Revised Use Case


4/23


Chapter:RevisedDomainModel

4

Revised Domain Model


5/23


Chapter:ProjectScope(Upd

atesfrom

DeliverableI)

5

Project Scope (Updates from Deliverable I)

Must Have

1. Productsy Ability to change price and name of producty Ability to add and remove stock

2. Paymenty Refunding of money should be dynamic, that is, if the user puts in 5 $2 notes and presses

refund, he should get a $10 note. If there are no $10 notes left, he should get the next

minimum amount of change required, which is 2 $5 notes, and so on. Similarly, if he

purchases a product, the change returned to him should be dynamic.

y Inform user that he is unable to buy a certain product if there is no change available.y Payment by card would result in the appropriate amount being deducted from it.y User has the option to insert both cash and card.

3. Displayy User will only be to select up to the maximum number of stocks left.

Constraints

1. Paymenty Although user can insert both cash and card, he is allowed to pay using only one of them.

For example, if the user needs to pay $10 in total, and he has inserted $8 cash and a $15

card, he would be allowed to pay only using the card, since there is insufficient case. The

case of deducting all $8 from the cash, and an additional $2 from the card (to give $10 in

total) is not possible.

2. Shelf/Productsy Each vending machine, once created, will have a fixed number of shelves and products per

shelf. It is not possible to add one more shelf, or remove a shelf from it. This is to simulate a

real vending machine, whereby you can have an empty shelf, but you cannot remove the

shelf itself from it.

3. Registery Accepts only Singapore currency.y


6/23


Chapter:Diagram

toIllustrat

eSub-Systems

6

Diagram to Illustrate Sub-Systems

GUI

ATD

APPLICATION

LAYER

STORAGE

LAYER

VMSettings.txt

VMState.dat


7/23

CS2103 S

e

ee

jec

Chapte

agramt

oIllustrateSub-Systems

7


8/23


Chapter:ClassDiagrams

8

Class Diagrams


9/23

CS2103Software Engineering Project

Chapter:ClassDiagrams

9


10/23

CS2103Software Engineering Project

Chapter:ClassDiagram

s

1

0


11/23


Chapter:InteractionDiagrams

1

1

Interaction Diagrams

Item Selection

Purchase Item


12/23


Chapter:StateCharts

1

2

State Charts


13/23


Chapter:StateCharts

1

3


14/23


Chapter:TestPlanand

TestCases

1

4

Test Plan and Test Cases

Test Items Table

Use Case Test

CaseNo.

Test Case Description ExpectedResults

Insert Cash CAa User attempts to insert

10 cent coin and 5 $10

notes.

After insertion of cash:

VM.getCurAmt(PaymentType.CASH) == 5010 (the cents

representation of $50.10)

InsertCash

CAb User attempts to insert

1000000 of 10 cent coins.

After attempted insertion of cash:

VM will have less than 1000000*10 cents and more than

0 cents. This is because the VM should not take in all the

1 million 10 cent counts, and at the same time it should

not discard all the coins. (It should take in up to its coin

containers physical limit)

Insert

Cash

CAc User attempts to insert a

20 dollar note.

After the attempt:

The Value Of The Payment Is Not Accepted By ThisRegister. Cash Refunded Exception Thrown

InsertCard

CRa User attempts to insert

card twice.

After the attempt:

There Is Already Another Card In This Register

Exception Thrown

PurchaseItem

PIa User attempts to select

negative quantity of

Product B.

After attempt to select:

Quantity cannot be negative Exception Thrown

PurchaseItem

PIb Select non-existent

(quantity = 0) Product

index 5 in Shelf index 0.

After attempt to select:

Quantity is not enough for such a selection Exception

Thrown

PurchaseItem

PIc Purchase Product C with

insufficient cash (9 $1

coins).

After attempt to purchase:

There Is Insufficient Cash To Deduct From Exception

Thrown

PurchaseItem

PId User inserts cash (9 $1

coins and 9 $2 notes) and

a cashcard (containing

$2) and attempts to pay

using card for Product A.

After attempt to purchase:

There Is Insufficient Balance To Deduct From Exception

Thrown

RemoveCard

RCa User inserts cash (9 $1

coins and 9 $10 notes)

and cashcard ($20). Then

removes the card and

attempts to pay for

Product A using card

payment method.

After attempting to insert the card:

Please Insert Card Exception Thrown


15/23


Chapter:TestPlanand

TestCases

1

5

RefundCash

RFa User inserts cash (9 50

cent coins and 9 $5

notes) and cashcard ($20)

and presses refund.

After attempting to purchase:

Exception expected There Is Insufficient Cash To Deduct

From"

Check whether the content of the box is correct.

Add Item AIa User changes thequantity of a Product A to

15 and attempts to buy

all of it with a cashcard

(containing exactly

15*Product A's price).

After quantity change:VM.getProductQty(0,0) == 15

After purchase:

VM.view_clearPurchaseCollectionBox() == Product:

Heineken, Price: $14.00, Qty: 15

AddProduct

APa User adds a new product.

Asahi Dry at Product

index 1 of Shelf index 0. It

has the following

properties: Price: $10.01.

Quantity 50. Attempts tobuy 25 of it.

After adding the product:

VM.getProductName(0,1) == Asahi Dry

VM.getProductPrice(0,1) == 1001

VM.getProductQty(0,1) == 50

After purchase:

VM.view_clearPurchaseCollectionBox() == Product:Asahi Dry, Price: $10.01, Qty: 25;

RemoveItem

RIa User changes the

quantity of Product A to 1

but attempts to select 2

to purchase.

After Removing Items:

VM.getProductQty(0, 0) == 1

After attempting to select the product:

Quantity is not enough for such a selection Exception

Thrown

RemoveProduct

RPa User changes the

quantity of Product C to 0

for an existing Product.

User then attempts toselect it.

After Removing Product:

VM.getProductQty(1, 9) == 0

After attempting to select the product:

Quantity is not enough for such a selection ExceptionThrown

ModifyProductPrice

MPa User modifies the price of

Product C to $12.01 and

selects 3 of it and checks

the amount. Then

attempts to use cash to

pay.

After Modify Product Price:

Insufficient change available Exception Thrown (since

machine does not contain 1 cent change)

RenameProduct

RNa User modifies the name

of Product B to

Marlboro Lights.

After Rename:

VM.getProductName() == Marlboro Lights


16/23


Chapter:TestPlanand

TestCases

1

6

MaintainCash

MCa User removes 10, 20, 50

cent coins from the

registers and attempts to

buy Product C with $20.

After removal of coins:

VM.getCashQty(CashType.COIN, 0) == 0



( This is because coin type 1, 2, 3 which are 10, 20, 50

cent coins are set to 0, $1 is left out )After attempting to purchase Product C:

Insufficient change available. Exception Thrown

- EXa User inserts one $1 coin.

User selects Product C.

User inserts one $10

note.

User purchases through

Cash payment method.

User inserts a card

(containing Product A's

price).User purchases through

Card payment method.

User only collects change

and items after all the

above actions.

After all actions:

VM.view_clearPurchaseCollectionBox() == "Product:

Viceroy Menthol Lights, Price: $10.50, Qty: 1

Product: Heineken, Price: $14.00, Qty: 1"

VM.view_clearCashCollectionBox() == "Type: COIN, Value:

$0.50, Qty:1"

Approach

Use cases are used to create most of the test case items. Hence, the test case items are organised by the

use case they originated from. Test case items also attempt to test boundary values wherever possible. An

example of this is in the Testing Tasks section where two of the products are placed at the first and last

indexes. Test cases also attempt to make use of Cash objects that lie at the boundary of the Register.

Keeping in mind that the Vending Machine will be a physical machine, additional test case items are

generated from the assumption that certain users may perform multiple tasks (use cases) and in different

orders.

The test case items are ordered in a way such that later test case items expect earlier test case items to pass.

Thus, having more components to test and becoming less atomic and more like a longer user story.

Item Pass/Fail Criteria

The boolean condition items specified in the "Expected Results" column must all evaluate to be true for each

test item.


17/23


Chapter:TestPlanand

TestCases

1

7

However, there are certain intermediate boolean conditions not specified here but used for unit testing to

terminate the test case item early and identify atomic failures. Testing for these failures should have been

done during unit testing but these tests are maintained and retested at this level for the purpose of

debugging and regression testing.

Testing Tasks

This is the prepared Settings class used for the Vending Machine class created for the test cases.

y Shelf 0 : Beery Shelf 1 : Cigarettey Maximum Products Per Shelf: 10

y Product A is Product 0 in Shelf 0: "Heineken" $14.00 with Quantity of 10y Product B is Product 0 in Shelf 1: "Marlboro Ice Mint" $11.50 with Quantity of 5y Product C is Product 9 in Shelf 1: "Viceroy Menthol Lights" $10.50 with Quantity of 7

y Quantity of 10 for each of the following coins: 10 cents, 20 cents, 50 cents and 1 dollary Quantity of 10 for each of the following notes: 2 dollars, 5 dollars, 10 dollars

This standard set of properties is used for all the test cases. Although randomization of certain factors can be

done, our approach to the System tests is to assume all features are enabled.

The test cases are written for the JUnit Framework. A formatted output from JUnit using the test runner

class TestDriver is used to determine the results of the testing.


18/23


Chapter:DesignConsid

erations>

1

8

Design Considerations

General Design

The two main design principles applied was tight cohesion and loose coupling. This is achieved by making

each component of the system modular. The cohesion of the component is kept to the minimum such that

any component can be swapped out easily and replace with another of the same type.

Simulation

The vending machine is a simulation hence the following considerations are made:

1. Cash and Productdispensed are being stored in a container until the user chooses to clear it. This isdone when the user view the content of the container

2. Cards are not stored by the vending machine. In the current implementation, the UI will store thecard. The user will select the card to be inserted through the UI.

3. The vending machine has a fixed number of shelves and fixed slots per shelf. These values cannot bechanged after the vending machine is created. It is designed as such because a real vending machine

often have these properties fixed and cannot be changed and is thus modelled accordingly.

4. The type of coins and notes that the machine can accept will be fixed once the vending machine iscreated. Again this is modelled closely to a real vending machine, as it is often hard or impossible to

change these because it involves hardware changes. According to the design, it is possible to change

the whole register but we did not allow that as a separate interface to modify the vending machine

would be needed.

5. Product is removed by removing all quantity in the slot and deleting the slot label.6. Product is added by increasing the quantity of an empty slot after changing the name of the slot.7. These simulate a real vending machine with slots for individual items where each slot has its own

label and quantity count.

Application Layer

Dynamic Design

Due to the simulation constraints, many properties of the vending machine have to be fixed. Nonetheless,

we wanted to have the ability to create a vending machine to our liking, that is, we can create a vending


19/23



erations>

1

9

machine with 1 shelf and 5 products per shelf, or 2 shelves and 15 products per shelf, and so on. The

following list the parts that are dynamic in the design.

1. Number of shelves2. Number of slots per shelf3. Number and types of coins accepted4. Number and types of notes accepted

However, by accepting different values of coins and notes, the problem for the refunding of cash or

returning of change becomes a complicated issue. Greedy algorithm not longer works for such a case and a

complete search will be too slow. Hence, dynamic programming is used instead to find the least amount of

cash (coins or notes) needed to refund the amount required.

Controller

The controller makes use of a Faade Pattern. The amount of operations being done in the Controller

(VendingMachine class) is kept to the minimum. Most of the operations are delegated out to the individual

component under the controller. TheVendingMachine class is the main opening of the application package

(layer).

SalesRecords

The SalesRecords class keeps track of all the transactions made. After each successful transaction, the

controller passes the collection of products purchased to the SalesRecords to create a new entry. The

printing of sales report is dedicated to the GUI layer because it can be easily done by Swing.

Register

TheRegisterclass handles all operations that deal with payment and money. Insertion of any form of

payment to the vending machine will go straight to the register. The type ofCash that will be accepted by

the Registeris determined during the construction of the object and no changes will be accepted after that.

If the Registerdetects any unaccepted Cash type being inserted, it will refund it immediately. When the user

requests for a cash refund, the register will calculate the combination of the type of cash to dispense using a

Dynamic Programming algorithm.


20/23



erations>

2

0

Multiset

A design similar to a multiset is used to represent the Productand Cash. Instead of having a collection of

items to represent each type, items are represented using the ItemCollection class that contains an

additional attribute, quantity. ACollectionBoxclass is used as a container for ItemCollection. Adding an

ItemCollection to the CollectionBoxwill increment the quantity of the ItemCollection if it already exists.

Another additional advantage of this data structure is that simulation of multiple products or cash addition

to the machine can be easily done.

Shelf

The Shelfclass keeps track of the current products available for purchase and the current selection made by

the user. This is done such that the GUI does not keep track of the user selection so that only one set of this

record is kept. The alternate consideration made was for the GUI to remember all the selection and pass it to

the shelf at once when the user chooses to purchase. The latter method is not used because by doing that

the GUI have to calculate the total cost of the selected item which again result in the same operation being

done on both the Shelfside and the GUI side.

StateSaving

The state of the vending machine can be saved and restore the next time the application is launched. This is

implemented using object serialization. This method was chosen because it is neater to implement and there

is no need for the user to edit the save state directly.

Settings

ASettings class consists of all the property needed to create a new instance of vending machine. This class is

used to create new VendingMachineobject as it has the following advantages:

1. Reducing coupling and complexity External classes that need to create custom VendingMachineneed not be dependent on other classes like Cash and Card. For any class that needs to create

VendingMachine, only the Settings class and theVendingMachine class are needed.

2. Check for invalid settings3. Creating VendingMachine object with the settings object will always be successful - the Settings class

has already reject all invalid inputs


21/23



erations>

2

1

4. The Settings class allows other module top build on top of it - For example, a SettingsEditorclass isavailable to edit settings using a GUI and a SettingsIO class is available to read and write settings

using text file.

In addition, the Settings Class features a public static method to create an instance with default settings. The

design pattern applied here is similar to factory method. This is used because it creates the default settings

in one step.

VMManager

This is the entry point for the entire application. The VMManagerwill use SettingsIO to load the saved

settings or load the SettingsEditorto allow the user to create a new set of settings. The VMManagerwill

then create a new instance of VendingMachine, which is subsequently used to create a new instance ofVMGUI. The loading and creating of new VendingMachine is not included in VMGUI or VendingMachine to

increase the cohesion of the classes. This design also increases the extensibility of the application.

Extensibility

Create, Save and Load Multiple Vending Machines.

Due to the modular design of the application and GUI layer, new instance of the VendingMachine can be

created and stored. Using the current GUI, multiple active vending machines can be loaded and shown on

the screen at the same time, without the need to modify any existing code. Each vending machine will have

its own set of properties.

Ability to Swap Out and Insert New Shelves and Register for Existing Vending Machine

The current design does not allow it, but it is relatively easy to add this feature due to the fact that Shelfand

Registerare standalone classes in the vending machine.

GUI Design

The GUI was designed such that each individual class within the GUI package is as cohesive as possible, while

still maintaining loose coupling. The following is a list of all the GUI classes, followed by a brief description

for each of them. After which, an elaboration of the design thought process and decisions will be given for

each class.


22/23



erations>

2

2

ListofGUIClasses

y VMGUI - The class that extends JFrame, used to hold all the other components together.y UserListPanel- A class that extends JPanel, and is used to display all product information relevant to

the user.

y ProductListPanel- A class that extends UserListPanel, and is used to display all product informationrelevant to the product administrator.

y RegisterListPanel A class that extends JFrame, and is used to display all register informationrelevant to the register administrator.

y SalesRecord- A class that holds the necessary components for displaying and printing the salesrecord.

y RightPanel- A class that contains all the buttons for inserting payment, as well as the buttons tochange the mode of the vending machine. In a way, it is a control panel.

y ListPanel- A class that extends JPanel, and displays x number of ListItems, depending on the numberof products passed to the constructor.

y ListItem - A class that extends JPanel, and is used for displaying the quantity, name and price of eachproduct.

DetailedElaboration

VMGUIVMGUI was initially the entry point (main method) for the vending machine application itself, but over time,

we decided to remove the I/O aspects of it, and created the new class, VMManager, to take charge of it. As

such, VMGUI will take in a VendingMachine in its constructor, and is instantiated by VMManager. Thus, the

entry point changed to becomeVMManagerinstead.

From the start, the goal of the team was to have a vending machine that was flexible, that is, we are able to

create a vending machine with any number of shelves (other than zero), and any number of products. In

addition to that, we wanted to make the type of values it can accept dynamic.

Due to the above reasons, VMGUI was designed as some form of controller for the UI. Other than a few

JTextField to display the status and current amount, and some JButtons for making payment, cancelling

transaction and collecting items, the rest of the GUI components were placed in their respective classes for

cohesiveness. To lessen the coupling, VMGUI had some public functions that were accessed by the other

methods.


23/23



erations>

2

VMGUI has a JPanel named basePanel, which is using CardLayout. It will switch between the 4 modes (User,

Product Administrator, Register Administrator, Sales Record), which are all using JPanels of their own.

UserListPanel

UserListPanelcontains xnumbers of ListPanels, depending on the number of shelves. All methods inUserListPanelare relevant only to the vending machine in user mode.

ProductListPanel

ProductListPanelextends UserListPanel, as they are virtually identical, except for the listeners, and that the

JTextFields are made editable instead. All methods in ProductListPanelare relevant only to the vending

machine in product administrator mode.

RegisterListPanel

RegisterListPanelextends JPanel. The number ofListItems generated is dependent on the types of coins and

notes. All methods in RegisterListPanelare relevant only to the vending machine in register administrator

mode.

SalesRecord

SalesRecordextends JPanel. The sales record has a text area which is set to view the sales record when

initialized. It also features the ability to print and reset the sales record. Printing is done via the use of a

SwingWorker.

ListPanel

ListPanelcontains xnumber ofListItems, depending on the number of products per shelf.

ListItem

ListItem contains one JSpinner (for quantity of product or cash), one JTextField (for name of product or value

of cash), and one more JTextField(for product price, or total amount of cash). It also contains various

methods to allow the other classes to set the listeners for the JSpinner and JTextFields directly.

CS2103 Software Engineering Project

Documents

Transcript of CS2103 Software Engineering Project