Reference no: EM131576938
Q1. Write a multithreaded application to simulate a football stadium ticket system. Four PurchaseType objects are linked to a TicketSystem object that allows for checking the number of available tickets and assigning them to a PurchaseType object. Only one PurchaseType object can buy tickets from the TicketSystem at a time. This may require synchronization between threads and the use of locks. There is a limit of four tickets per transaction.
These days there are a number of methods available for purchasing tickets. Tickets can be purchased over the counter in a retail outlet, over the phone with a customer service agent, online with a one-off transaction or online using a 1-click method, where all customer details and payment information are submitted to the system with a single mouse click. Your system should contain four instances of PurchaseType to reflect these purchase methods: retailPurchase, telephonePurchase, onlineOnce, onlineAccount. Each of the purchase methods has strengths and weaknesses. A retailPurchase takes 30-90 seconds to complete, a telephonePurchase takes 90-180 seconds to complete, an onlineOnce purchase takes 180-300 seconds to complete and an onlineAccount purchase takes 10-30 seconds to complete. However, a retailPurchase will cost the system €5 per transaction based on staff and premises costs. A telephonePurchase will cost the system €3.50 per transaction based on similar costs, an onlineOnce costs €0.50 per transaction due to server costs and an onlineAccount purchase costs €1 per transaction due to server costs, database maintenance and security costs.
Simulate a scenario where 80,000 seats are available for a championship game and each of the PurchaseType objects has a steady queue waiting to purchase tickets on a continuous basis. Simulate different customer requests (between 1 and 4 tickets). If less than the requested number of tickets are available, then the next highest amount of tickets should be allotted and an appropriate message displayed to the system output. To speed up the simulation use 10 milliseconds to represent 1 second. Each PurchaseType should have its own thread and take exclusive control of the TicketSystem for the duration of its transaction. Transaction times are not affected by the number of tickets being purchased but the times should fluctuate between the upper and lower ranges to simulate a more realistic system.
Messages should be displayed to the system output to indicate that the tickets have gone on sale, to display any warning messages about insufficient ticket numbers, and to indicate when a PurchaseType object can no longer buy tickets. Messages giving the total sales, total time and total cost to the system for each PurchaseType object should also be displayed at the end of the simulation.
Q2. Imagine that you have been contracted to write an application that tracks and manages files being moved from one storage location to another. Your application should be able to support the following actions: 1) Examine a designated file share. 2) Zip up existing directories. 3) Log the name of the zipped file, time it took to transfer the file and the size of file.
Given the above information, write a class that achieves the three goals above. Allow for cases where no path is specified at initialization, a path is specified, or a path and zip file name are specified. Write a test class that declares and initializes two instances of your file handling class, tests their methods appropriately and displays relevant information on screen. Your application should include appropriate use of inheritance and interfaces and allow for common file handling errors.