CS2103 Software Engineering Project

CS2103 Software Engineering Project
Vending Machine
Deliverable II AHMED SHAFEEQ BIN MOHD SHARIFF CHUA KIEN CHUAN Team 5 CHIN SOH YUAN TAN YAN HAO
U080022Y U087140B U087201B U087137L
shafeeq@nus.edu.sg cchua@nus.edu.sg sohyc@nus.edu.sg tyanhao@nus.edu.sg
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
Chapter: Revised Use Case
Revised Use Case
Chapter: Revised Use Case
Revised Domain Model
Chapter: Revised Domain Model
Project Scope (Updates from Deliverable I)

Must Have
1. Products
y y
Ability to change price and name of product Ability to add and remove stock
2. Payment
y
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 y y
Inform user that he is unable to buy a certain product if there is no change available. Payment by card would result in the appropriate amount being deducted from it. User has the option to insert both cash and card.
3. Display
y
User will only be to select up to the maximum number of stocks left.
Constraints
1. Payment
y
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. Chapter: Project Scope (Updates from Deliverable I)
2. Shelf/Products
y
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. Register
y y
Accepts only Singapore currency.
Diagram to Illustrate Sub-Systems
GUI
APPLICATION LAYER
STORAGE LAYER
VMSettings.txt VMState.dat
ATD
Chapter: Diagram to Illustrate Sub-Systems
Chapte

agram to Illustrate Sub-Systems

e ee jec
CS2103 S
Class Diagrams
Chapter: Class Diagrams
1 0
Interaction Diagrams
Item Selection
Purchase Item
1 1
Chapter: Interaction Diagrams
State Charts
1 2
Chapter: State Charts
1 3
Chapter: State Charts
Test Plan and Test Cases

Test Items Table
Use Case Test Case No. CAa Test Case Description Expected Results
Insert Cash
Insert Cash
CAb
User attempts to insert 10 cent coin and 5 $10 notes. User attempts to insert 1000000 of 10 cent coins.
Insert Cash
CAc
User attempts to insert a 20 dollar note .
After insertion of cash: VM.getCurAmt(PaymentType.CASH) == 5010 (the cents representation of $50.10) 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 it s coin container s physical limit) After the attempt: The Value Of The Payment Is Not Accepted By This Register. Cash Refunded Exception Thrown After the attempt: There Is Already Another Card In This Register Exception Thrown After attempt to select: Quantity cannot be negative Exception Thrown After attempt to select: Quantity is not enough for such a selection Exception Thrown After attempt to purchase: There Is Insufficient Cash To Deduct From Exception Thrown After attempt to purchase: There Is Insufficient Balance To Deduct From Exception Thrown Chapter: Test Plan and Test Cases
Insert Card
CRa
User attempts to insert card twice.
Purchase Item Purchase Item Purchase Item Purchase Item
PIa
PIb
PIc
PId
User attempts to select negative quantity of Product B. Select non-existent (quantity = 0) Product index 5 in Shelf index 0. Purchase Product C with insufficient cash (9 $1 coins). User inserts cash (9 $1 coins and 9 $2 notes) and a cashcard (containing $2) and attempts to pay using card for Product A. 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.
Remove Card
RCa
After attempting to insert the card: Please Insert Card Exception Thrown
1 4
Refund Cash
RFa
User inserts cash (9 50 cent coins and 9 $5 notes) and cashcard ($20) and presses refund. User changes the quantity of a Product A to 15 and attempts to buy all of it with a cashcard (containing exactly 15*Product A's price). 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 to buy 25 of it.
After attempting to purchase: Exception expected There Is Insufficient Cash To Deduct From" Check whether the content of the box is correct. After quantity change: VM.getProductQty(0,0) == 15 After purchase: VM.view_clearPurchaseCollectionBox() == Product: Heineken, Price: $14.00, Qty: 15
Add Item
AIa
Add Product
APa
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 ;
Remove Item
RIa
User changes the After Removing Items: quantity of Product A to 1 VM.getProductQty(0, 0) == 1 but attempts to select 2 After attempting to select the product: to purchase. Quantity is not enough for such a selection Exception Thrown User changes the quantity of Product C to 0 for an existing Product. User then attempts to select it. After Removing Product: VM.getProductQty(1, 9) == 0 After attempting to select the product: Quantity is not enough for such a selection Exception Thrown
Remove Product
RPa
Modify Product Price
MPa
Rename Product
RNa
User modifies the name of Product B to Marlboro Lights .
After Rename: VM.getProductName() == Marlboro Lights
1 5
Chapter: Test Plan and Test Cases
User modifies the price of After Modify Product Price: Product C to $12.01 and Insufficient change available Exception Thrown (since selects 3 of it and checks machine does not contain 1 cent change) the amount. Then attempts to use cash to pay.
Maintain Cash
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 VM.getCashQty(CashType.COIN, 1) == 0 VM.getCashQty(CashType.COIN, 2) == 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 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"
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.
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. Chapter: Test Plan and Test Cases
Item Pass/Fail Criteria

The boolean condition items specified in the "Expected Results" column must all evaluate to be true for each test item.
1 6
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 y y
Shelf 0 : Beer Shelf 1 : Cigarette Maximum Products Per Shelf: 10
y y y
Product A is Product 0 in Shelf 0: "Heineken" $14.00 with Quantity of 10 Product B is Product 0 in Shelf 1: "Marlboro Ice Mint" $11.50 with Quantity of 5 Product C is Product 9 in Shelf 1: "Viceroy Menthol Lights" $10.50 with Quantity of 7
y y
Quantity of 10 for each of the following coins: 10 cents, 20 cents, 50 cents and 1 dollar 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.
1 7
Chapter: Test Plan and Test Cases
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 Product dispensed are being stored in a container until the user chooses to clear it. This is done 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 the card. 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 be changed 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 accord ingly. 4. The type of coins and notes that the machine can accept will be fixed once the vending machine is created. 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 Chapter: Design Considerations> 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
1 8
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 shelves 2. Number of slots per shelf 3. Number and types of coins accepted 4. 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. The VendingMachine 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
The Register class 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 of Cash that will be accepted by the Register is determined during the construction of the object and no changes will be accepted after that. If the Register detects 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.
1 9
Chapter: Design Considerations>
Multiset
A design similar to a multiset is used to represent the Product and 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. A CollectionBox class is used as a container for ItemCollection. Adding an ItemCollection to the CollectionBox will 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 Shelf class 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 Shelf side and the GUI side.
State Saving
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
A Settings class consists of all the property needed to create a new instance of vending machine. This class is used to create new VendingMachine object as it has the following advantages: 1. Reducing coupling and complexity External classes that need to create custom VendingMachine need not be dependent on other classes like Cash and Card. For any class that needs to create VendingMachine, only the Settings class and the VendingMachine class are needed. 2. Check for invalid settings 3. Creating VendingMachine object with the settings object will always be successful - the Settings class has already reject all invalid inputs Chapter: Design Considerations>
2 0
4. The Settings class allows other module top build on top of it - For example, a SettingsEditor class is available 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 VMManager will use SettingsIO to load the saved settings or load the SettingsEditor to allow the user to create a new set of settings. The VMManager will then create a new instance of VendingMachine, which is subsequently used to create a new instance of VMGUI. 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 Shelf and Chapter: Design Considerations> Register are 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.
2 1
List of GUI Classes

y y
VMGUI - The class that extends JFrame, used to hold all the other components together. UserListPanel - A class that extends JPanel, and is used to display all product information relevant to the user.
ProductListPanel - A class that extends UserListPanel, and is used to display all product information relevant to the product administrator.
RegisterListPanel A class that extends JFrame, and is used to display all register information relevant to the register administrator.
SalesRecord - A class that holds the necessary components for displaying and printing the sales record.
RightPanel - A class that contains all the buttons for inserting payment, as well as the buttons to change the mode of the vending machine. In a way, it is a control panel.
ListPanel - A class that extends JPanel, and displays x number of ListItems, depending on the number of products passed to the constructor.
ListItem - A class that extends JPanel, and is used for displaying the quantity, name and price of each product.
Detailed Elaboration VMGUI

VMGUI 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 become VMManager instead. 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. Chapter: Design Considerations>
2 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
UserListPanel contains x numbers of ListPanels, depending on the number of shelves. All methods in UserListPanel are relevant only to the vending machine in user mode.
ProductListPanel
ProductListPanel extends UserListPanel, as they are virtually identical, except for the listeners, and that the JTextFields are made editable instead. All methods in ProductListPanel are relevant only to the vending machine in product administrator mode.
RegisterListPanel
RegisterListPanel extends JPanel. The number of ListItems generated is dependent on the types of coins and notes. All methods in RegisterListPanel are relevant only to the vending machine in register administrator mode.
SalesRecord
SalesRecord extends 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
ListPanel contains x number of ListItems, 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. Chapter: Design Considerations>
2 3

CS2103 Software Engineering Project

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS2103 Software Engineering Project

Uploaded by

Copyright:

Available Formats

CS2103 Software Engineering Project

U080022Y U087140B U087201B U087137L

shafeeq@nus.edu.sg cchua@nus.edu.sg sohyc@nus.edu.sg tyanhao@nus.edu.sg