Coursework CSC8016
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
• In a realistic example, communications happen between processes via UDP messages. In this
module, we don’t require that. We can freely assume that each client (Physical person buying
items in the show using the mobile app, OnLine Shopper) is mimicked by one single thread. We
assume they directly exploit such an interface (no FrontEnd is required!)
1
• If the RainforestShop is implemented as a server, such a thread might receive the “client messages” through shared variables.
• The RainforestShop already comes with a Transaction class keeping track of the transactions
that are performed for handling basketing operations. You are not required to tolerate the
server crash (this is more of a back-up task rather than a concurrent programming one), but
you must correcly handle client log outs (withdrawn items from the shelves after log-out should
be automatically re-shelved with a cookie-free assumption, where the basket is not “rembered”
after re-logging in)!
• We assume that the RainforestShop class is initialized with the users allowed to shop using
the mobile app or OnLine website (Collection client_ids), the association between
the name of the product (String), its cost (Double) and a non-zero Integer number of available items to purchase (Map