1. Design Problem & Solution By Team 7 PT

2. Summary of Problems and Solutions Design Problem Candidate Patterns Motivation of Selection Structure of the Pattern Collaboration among Participants Implementation Decisions

3. IndexDesign ProblemProposed Solutions 1Once a DrinkStoreItem get decreased, more than one UI updates need to be done. So The synchronization between UI classes need to be performed to update the value and status correctly Observer 2The TransactionController contains various behavioural states that are currently executed sequentially according to the use case flow. The states are not concrete enough within TransitionController even though the use cases for it suggest that there is a transition in behavior of the TransactionController. State / Factory Method / Singleton 3When giving change, the Change Giver is looping for each denomination, starting from the largest to the smallest, stored in CashStoreItem. When looping denomination value, the Change Giver needs to find out which CashStoreItem which has that denomination. The list of denomination value might be not in the correct sequence from the largest value when giving change. Iterator 4 There are different types of drink selection box in real vending machine. Some of them are simple single touch buttons. But, some vending machine requires pressing sequence of buttons either combination of numbers or combination of alphabetic character and number. Template 5Current UI interface only cater to awt's platform. in future it can be extend to other platform or theme. Abstract Factory / Singleton / Adapter 6VMCS data persistency heavily depends on CashPropertyLoader and DrinkPropertyLoader. Both of the implementation is based on the concrete classes without further abstraction or Interfaces. Bridge / Abstract Factory

4. Store controller has concrete dependency on Property Loader classes Currently only support one kind of persistence mechanism Changing persitence mechanism results in re- compiling Store Controller class and the underlying related classes

5. The old design violates dependency inversion principles

6. Abstract Factory Pattern Bridge Pattern

7. Persistency of VMCS could have different implementation for different requirements and system environments. Avoid permanent binding towards concretion Hiding concrete implementation from the client Improve extensibility

10. Cash Store File Based : StoreController : CashStorageLoader : StorageFactory : FileStorageFactory : CashFileStorage : Environment 1: initializeStore( ) 2: initializeCashStore( ) 3: new CashStorageLoader( ) 4: initialize( ) 5: getInstance( ) 6: isStorageModeFile( ) 7: new FileStorageFactory() 8: createCashStorageEngine( ) 9: new CashFileStorage( ) 10: getItem( )

11. Cash Store XML Based 6: isStorageModeFile( ) : StoreController : CashStorageLoader : StorageFactory : XmlStorageFactory : CashXmlStorageEngine : Environment 1: initializeStore( ) 2: initializeCashStore( ) 3: new CashStorageLoader( ) 4: initialize( ) 5: getInstance( ) 7: new XmlStorageFactory() 8: createCashStorageEngine( ) 10: getItem( ) 9: new CashXmlStorageEngine( )

12. Abstract Factory StorageFactory will serve as abstract factory FileStorageFactory and XmlStorageFactory will serve as concrete Bridge Pattern StorageLoader will serve as abstraction CashStorageLoader and DrinkStorageLoader serve as Refined abstraction FileStorageEngine as default implementor CashFileStorageEngine and DrinkFIleStorageEngine as Concrete implementor