Coursework CSC8016 Project 2: Virtual Shopping system
Use Case Scenario
We want to implement a virtual shopping system, whether the threads are either clients using the web app, or clients buying products on the physical shop using the mobile app. The lifecycle of any client interaction is summerised by ClientLifecycle: Each client interacts with the shop through the RainforestShop via the login method, through which each client can add items to its basket and perform re-shelving operations (moving the items back to the physical/virtual shelf from the basket). Each client can get a list of available items at the time of the query, basket a given product by name, (re)shelf the product (thus removing it from the basket), checkout and proceed with the payment (thus either buying all the items on the basket or none of those entirely), and logging out of the system while losing the information of all the items being previously put in the basket from the real/virtual shelf (thus entailing implicit re-shelving).
Each time an allowed user logs in, a non-empty transaction will be created with an unique transaction ID. The unavailability of the product shall be confirmed not while basketing the items, rather than after purchasing those. At this stage, the shop supplier (SupplierLifecycle) might be notified that some products are missing (getNextMissingItem) and refurbish the show with a non-zero amount of products of the same type (refurbishWithItems). For simplicity sake, the refurbishWithItems method will be in charge of creating the number of desired product and to place them on the shelf.
As in any industrial setting where teams split up the duties, you are assigned an API that you need to implement. Such an API is provided both on Canvas and at https://github.com/jackbergus/NCL_CSC8016/tree/main/src/main/java/uk/ncl/CSC8016/jackbergus/coursework/project2. This will then require to finalise the implementation of RainforestShop and the integration of concurrency mechanisms in ProductMonitor; the Transaction class shall not be changed! The Testing solves a twofold task: showing how Clients, Suppliers, and the Shop system are communicating, as well as providing some preliminary guidelines on how the coursework is going to be assessed. The student is free to choose whichever is the best way to pass the tests (not fully disclosed to the students) in the Testing class. E.g., the RainforestShop could be either modelled as a finer-grained monitor, but inside this monitor at least one thread per logged user should be running; also, such a RainforestShop could be also implemented as a consumer threads handling all of the clients’ messages.
Assumptions
Submission Requirements
RainforestShopandProductMonitorshould be finalised, as the current implementation does not pass the provided tests!Submit the code as a zipped Maven project. with no jar and classes. The source code will be recompiled from scratch, and no jar/class is going to be run.
If you want to use an external Java library, please consider the following:
The Java library should be explicitly described as a
<dependency>in thepom.xmlfile, and should only access the libraries from the default Maven Central Repository.A library might provide single concurrency mechanisms primitives, but not ready-made solutions already composing those: semaphores, monitors, locks, just logs, thread barriers, thread pools, passing le baton mechanisms are allowed. Code reuse from the exercises and examples seen in class is permitted.
Systems completely solving the coursework for you are strictly prohibited: e.g., any kind of (data) management system having concurrency control (ensuring safe concurrent thread access to any data representation) and supporting concurrent transactions (implementing any kind of transaction protocol, either pessimistic or optimistic) must be avoided, as they both implement commit/aborts and thread-safe operations on data.
None of the (direct or indirect) dependencies of the coursework should rely on external servers or processes to run or to be installed.
The solution should not include external jar files.
If unsure whether the solution might be exploited, please ask before submitting.
Attached to the source code, please provide a short report motivating the compliance of the source code to each point and sub-point of the marking scheme. Providing such report in form of comments in the implementation is also fine. New classes might be created for supporting the implementation, but existing classes should be neither renamed or moved to a different package.
