FIRE organisation manages a number of luxury resorts | My Assignment Tutor

7COM1015 Referred Cwk:  Fantasy Islands Resort Experience (FIRE) Background The FIRE organisation manages a number of luxury resorts. Each resort consists of a group of small islands offering a range leisure facilities. Each island is connected by a ferry to one of more of the other islands of the resort. When guests arrive, they get a card (like a credit/debit card) which they can use for making payments at the resort. A card records a number of credits, and in this assignment, we are concerned with using cards to pay for ferry journeys. The number of credits on a card depends on the type of card, and guests can always buy more credits. However, before a card can be used to pay for a ferry journey, a number of conditions need to be met Recently, a number of incidents have occurred, which have convinced FIRE that they need a better system for tracking people at their resorts and they have decided to use the cards to do this. This project will initially be implemented at the Wayward Islands Resort (and then rolled out to other resorts). System Requirements FIRE will locate people (guests and staff)  by tracking their cards The following basic functional requirements have been established for the proposed system:Display details of the whole resortList all cards on all islands of the resortList all cards currently on a specified islandFind the current location of a cardAuthorise a ferry journey, if it meets the required conditionsAdd more credits to a cardConvert loyalty points into credits (Business cards only) The following data requirements have been established:Resort Each resort has a network of islands joined by ferries. A resort must always have a “Base” island which stores the cards for everyone who arrives. Its name MUST always be “Base” and it MUST have a rating of 0 and a large maximum capacity. All cards registered at a resort are initially added to this “Base” island. Island – a resort has a network of islands Each island has an id number, a name, a rating and a capacity (the maximum number of people (cards) that can be on the island at any one time). Each island should maintain a list of all cards currently on that island. These lists should be updated whenever a card enters or leaves a island, so that it is always possible to say who is currently on a island and to find the island location of a person as specified by their card Card – the resort has a collection of cards There are currently three types of cards: Tourist, Business, Employee (but further types e.g. Child, Silver will be introduced later). Information stored on all cards includes: a card ID number, person’s name, a luxury rating and a number of credits. The card id should be provided sequentially by the FIRE system. The luxury rating (1 to 10) determines the islands which the person is allowed to visit e.g. a card with a rating of 3 is allowed to visit to all islands rated 3 or below. A card is created on the system with an initial number of credits which are decremented when its owner makes a ferry journey. People may top up their credits at any time. (Handling payments to buy credits is outside the scope of this project). In addition, different types of cards include additional information or operations: Tourist card:is created with a specified luxury rating and a number of credits determined by parameter valuesdeduct 4 credits whenever a ferry journey is madealso includes citizenship (country from which the person comes) Business cardare created with a specified luxury rating, 30 credits and 20 loyalty pointsdeduct 3 credits and add 2 loyalty points whenever a ferry journey is madeloyalty points can be converted into credits (5 loyalty points = 1 credit) Employee cardare created with the highest luxury rating of 10 (Employees can visit all islands) and no creditsinclude an employee number, a job description, a journey scoredo not deduct any credits for a journey, but add 1 to the journey score whenever a ferry journey is madeFerry journey– connects two islands of the resort Each ferry journey has a journey code and connects a source island to a destination island. It represents a journey in one direction only. To make a ferry journey, certain conditions must be met.  If these conditions are met, the system allows the person onto the ferry to travel to the destination island. It updates its records to show that a card has left the source island and has travelled to the destination island. It also updates the card’s credits and other information, as appropriate. A request by someone(card) to make a ferry journey will produce one of the following results: Refusal to enter the ferry, because :the card’s luxury rating is lower than the rating of the destination island.the arrival of the card would exceed the maximum capacity of the destination island.the card does not have enough credits for the ferry journeythe card is not listed in the source island for the ferryno such card, or no such ferry in the systemSuccessful entry, because none of the above conditions is true                                                                You should assume that in this initial version of the system, credits are only used to cover the costs of ferry journeys. A card arriving or leaving the whole resort is also outside the scope of this assignment. The Assignment Produce a BlueJ project implementing FIRE system by completing tasks described below.  Your project must be capable of running correctly in the BlueJ package specified for this module. Your FIRE project should display the qualities associated with good program design: Your system should minimise code duplication and be modularised so that components have low coupling and high cohesion. So, you will be expected to use inheritance, abstract classes and interfaces.You should aim to make your code reusable and easy to maintain.Program code should be well documented, displaying both agreed standards of internal documentation.. Code which does not compile may be included as comments Assignment Tasks Marks awarded for tasks below total 120. Your mark will be then converted to a % Task 1 – simple inheritance                                                                     20 marks                                   The Java project RefCwk-students which can be downloaded from Studynet includes a first draft of a Tourist class which currently (and wrongly!!) stores all information and methods of a Tourist card.  Much of its code is also required by other card classes. In this task you should refactor this part of the system to minimise code duplication and take advantage of inheritance. Consider the advantages of an abstract parent class. re-factor the current Tourist class so that the information common to all card classes is moves to a parent class called Card, so that Tourist, Business and Employee classes can inherit from it.  Your code for these classes should minimise code duplication and take full advantage of inheritance. Tourist, Business and Employee classes should then store data/methods unique to these cards Task 2 – Testing inheritance                                                                   10 marks Add a CardTest class which will test your implementation of Task 1. You should include code which: creates a polymorphic data structure storing references to the different types of Card objects (use Appendix A). show by iterating through your data structure that the runtime system uses the dynamic type of an object to determine which implementation of a method to use. include a call to test at least one method defined only in the parent class,  one overridden method and one call to a method which is unique to a subclass Task 3 – Implementing the basic FIRE system                                  40 marks Your project should have the following classes: class Card and it subclasses , as described in tasks 1 & 2 above class Island & class Ferry should include:suitable fields as specified above.a suitable range of accessors/mutators to process data held by the classa method toString()which returns a String representation of an object of that class.Island should include a collection to store the reference of cards. Ensure relevant parameters are passed to the constructorFerry class should have a source island and a destination island to show its journey. These two island objects together with the ferry code should be passed as parameters to the island constructor. Without these classes you will find it difficult to develop the remaining classes. To begin with, you do not need to fully implement these classes,  but may add further fields/methods as your develop your solutions interface ResortControl Specifies methods required to provide system functionality.  A fully documented version of the ResortControl is available on Studynet.and you have nothing further to do in this class.    You must NOT change this class (except as required for the demonstration). class ResortUI        Provides a command line user interface to meet the functional requirements specified above It will compile (but not work well) even if you have not yet written the implementation for Resort some code has been provided, you must provide the code for other menu optionsyou should use the  Scanner class to capture input from the user   (not JOptionPane)this class should only call methods specified in  ResortControl class Resort – a skeleton of this class is included in  RefCwk-students It must implement the interface ResortControl. , but there are also some additional private methods Your implementation should have : three collections to store references to:all islands, all ferries & all cardsthe collection of all islands should be an Arraylist where the position of the island in the ArrayList is the same as its number i.e. Island 0 should be in location 0 of the ArrayListfor ease of programming, all ferries could be a HashMap (with the ferry code as the key)cards may be stored in whatever type of collection you consider suitable a constructor whichsets the resort location from a parameter value (see constructor header)it should then call two private methods,  defined at the end of the classloadIslandsAndFerries – which creates all the islands in Appendix A, and adds them to the collection of islands. These should be added in the order of their id numbers. It also creates all ferries (passing island objects as parameters to their constructors) and adds them to the collection of ferries.loadCards – should create all cards and add them to the collection of cardsFinally, the constructor should add all of the cards to the “Base” island the class should then provide implementation for all methods in the interface  ResortControl .  any additional methods which you may/should want to add to improve the design (but which are not specified in the interface) should be declared as private [3 private methods to return each type of object (ferry, card, island) using its key may be useful] You are reminded of the object-oriented design guideline: “the class that stores the data should process the data”, so only provide accessors and mutators in supplier classes which are really necessary. You may add any methods or classes you consider necessary to improve the design of the system, and to simplify the writing of client code. If you are unable to provide a full implementation of ResortControl in your Resort class, comment out unimplemented methods of ResortControl, so that Resort compiles Task 4 – System Testing                                                                           20 marks You can test your code by running the ResortUI but you will eventually find this tedious.  So, we have provided a skeleton Tester class which: declares a variable of class ResortControl.  Since ResortControl is an interface. an object of the Resort class (using polymorphic creation) is created for the Wayward Islands resort.already has a main() to make it runnable (see ResortUI main())has  a doTest() method in which you should write code to call methods on the ResortControl variable in a way which tests your system and demonstrates that it works according to specification. You should include appropriate output to the terminal window. You must also use comments to explain what is being tested. Marks for this task will be awarded for: the appropriate choice of data,the sequencing of method callsexplanations of tests. We are looking for evidence of a systematic approach to testing and will expect you to show that you have identified and tested for the main events likely to occur when the system is running. At this stage, you may ignore the situation where a card visits an island but has insufficient credits to return to the “Base” island. Task 5 – System Documentation                                                           5 marks You should produce:: a visually neat and readable UML-style class diagram of your system within the BlueJ project program code should be well documented, displaying both agreed standards of internal documentation and good use of the facilities available in Javadoc. (ResortControl is already well documented) Task 6 – Demonstration                                                                            25 marks At the time shown below (AFTER the assignment hand-in) , you will be asked to demonstrate that you have a good working knowledge of the code that you submitted. This will require you to have: internet access to Studynet at the start and end of specified timeBlueJ. set up on your own computer You will be asked to download to your computer, your original project and the written demo specification posted to Studynet.  In a timed session of 100 minutes, make the specified changes to the project on your own computerthen upload their zipped amended project to the RefCwk – Demo assignment slot. Note: you do not need to have internet access for the whole session. It will be enough if you download at the beginning of the session, work on your computer during the session and upload the result at the end of the session.  However, you should be aware that uploading at the end may take time and should allow at least  5 mins before the end time for uploading. The main purpose of the demonstration is to authenticate your code by showing that you know it well enough to use it and make these changes. If you do not undertake this demonstration, your assignment will get ZERO marks. You may be asked to: add a card tester classwrite a demo class to test the functionality of your systemadd a specified card subclassadd a new class, or methods to an existing classamend Resort to create a resort with small changes to the Wayward Island Resort Marks for the demonstration will be for code which performs the specified tasks, not for producing correct output. To see the type of tasks which could be asked, see the mock demo posted for the original STARS assignment Marking & Feedback Marks awarded on the feedback sheet total 120 and will then be converted to a %. The submitted assignment will be marked using a combination of automated testing and visual inspection of code which will form the basis for individual marks. So do NOT to change method signatures in Resort & ResortControl Your performance in the demonstration will put a limit on the marks you get for the coursework. In addition, a serious mismatch between your submitted work and your performance in the demonstration may result in proceedings for plagiarism/collusion.   The limits on coursework marks are as follows: Demonstration MarkMaximum % Coursework Markmark < 3203


Leave a Reply

Your email address will not be published.