Xanadu Multi-Access System-XMAS: A Project for Managing Access to Recreational Facilities

Task 1 - Simple Inheritance

Xanadu Multi-Access System-XMAS

The Xanadu Corporation manages a number of luxury recreational facilities which it calls “domes”. Each dome has a network of “pleasure caverns” with a range of delights for users to experience. Part of the experience is exploring the network of caverns to see what is available. Xanadu require a system which both controls access to each cavern and keeps track of users in the dome. Users move around the dome through gates operated by card readers. Users may opt for different types of pass cards which determine which caverns that they can access. The Health & Safety Council has expressed concerns about XMAS’s ability to ensure staff and users’ safety in the event of a major incident. This project will initially be implemented at the Paradise Park Dome (and then rolled out to other domes).

System Requirements

Any user moving in/out, or within, the dome must have a pass which will be used at doors. The system will regard the pass as equivalent to a user. All users issued a pass are required to sign an undertaking not to give the pass to anyone else. However, it is not within the scope of this computer-based system to ensure compliance.

1. The following basic functional requirements have been established for the proposed system:
   • Display the whole dome ; passes in all caverns
   • List all passes in all caverns of the dome (by cavern)
   • List all passes currently in a specified cavern
   • Find the current location of a user(pass)
   • Authorise entry through a door, if required conditions are met
   • Top up a user’s tokens
   • Convert points to tokens (Gol passes only)
   • Move a pass(user) to the outside of the dome
   • Evacuate all passes (users) to outside the dome.

1. The following data requirements have been established:
   • Dome

Each dome has a network of caverns joined by one-way doors. When users are not in the dome they are recorded as being in the “Outside” cavern. A dome must always have an “outside” cavern from which users (passes) start their experience. Its name MUST be "Outside" and it MUST have a rating of 0 and a large maximum capacity. All users registered to a dome are initially added to this “outside” cavern.

• Cavern - The dome has a collection of caver

Each cavern has a name, a rating and a capacity which is the maximum number of users that can be in the cavern at any one time. Each cavern should maintain a list of all passes currently in the cavern. These lists should be updated whenever a pass is used to enter or leave a cavern, so that it is always possible to say which pass is currently in the cavern and to find the location of a user as specified by their pass

• Pass(user) At any point in time, the dome has a collection of passes(users)

There are currently three types of user passes: Business, Gold, Staff (but there are plans to introduce further types of passes e.g. Child, Gold). Information stored on a pass usually includes: a user id number, user name, a rating and number of tokens, but different types of passes will contain additional information. The rating (1 to 10) determines the caverns which the user is allowed to visit e.g. a user with a rating of 3 is allowed to visit to all caverns rated 3 or below. A user is created on the system with tokens based on an initial payment. Tokens are decremented at a door when a user enters a cavern. Users may top up their tokens at any time by making appropriate additional payment. (Handling payments is outside the scope of this project.

• Business Pass:
  • is created with a specified rating and tokens determined by parameter values
  • requires the name of the company
  • deduct 4 tokens for each cavern visited

• Gold Pass

• is created with a specified rating, 30 tokens and 10 loyalty points
• deduct 3 tokens for each cavern visited
• add 2 loyalty points for each cavern entered
• loyalty points can be converted into tokens (5 loyalty points = 1 token)
• Staff Pass
  • are created with the highest rating of 10 (staff can visit all caverns)
  • include an employee number, a job title and the number of tokens set to 5
  • one token is deducted for each cavern visit

• Door – connect some of the caverns at the dome

Task 2 - Testing Inheritance

Each door has a door number and connects a source cavern to a destination cavern. It allows transit in one direction only. To get through a door, a pass must meet certain conditions. If these conditions are met, the system allows the pass (hence the user) through the door into the destination cavern. It updates its records to show that the pass has left the source cavern and gone into the destination cavern. It also updates the pass's tokens and other pass information, as appropriate.

A request by a user to go through a door will produce one of the following results: Refusal to enter a cavern, because|:

• the pass does not have enough tokens
• the pass rating is lower than the rating of the destination caver
• the entry of the user would exceed that destination cavern's maximum capacity.
• the user’s pass is not listed in the source cavern
• no such door
• no such pass

Successful entry, occurs when all of the above conditions are false

In this coursework, we are not concerned with the financial side of this system. Different domes have different fees structures and charges which will be used to convert a user's payments into tokens and to determine a user’s rating.

Produce a BlueJ project implementing a version of XMAS by completing tasks described below. Your project must be capable of running correctly on the software in UH labs.Your XMAS 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.

• 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 inter
• 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
• Marks shown for each task include marks for both functionality and
• Only Tasks 1- 3 are essential for the However, code in Task 4 can speed up coding during the demo.
• Your project must compile. Code which does not compile may be included as comments
• You must attend the demonstration If you do not attend the demonstration, you will get ZERO marks.

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 Cwk2-students which can be downloaded from Studynet includes a first draft of a Business class which currently (and wrongly!!) stores information about a Business pass. Much of its code is also required by other pass classes. Refactor this part of the system to minimise code duplication and take advantage of inheritance

• re-factor the current Business class so that the common information is moves to a Pass class, so that Business, Gold and Staff classes can inherit from it. Your code for these classes should minimise code duplication and take full advantage of inherit
• Business, Gold and Staff classes should then store data/methods unique to these passes
• consider the advantages of using abstract classe

Add an InheritanceTest class which will test your implementation of Task 1. You should include code which:

• create a polymorphic data structure storing references to the different types of Pass 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
• 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

• class Pass and it subclasses , as described in tasks 1 & 2 above
• class Cavern & class Door should include:
  • suitable fields as specified above.
  • a suitable range of accessors/mutators to process data held by the class
  • a method toString()which returns a String representation of an object of that cl
  • Cavern should include a collection to store the reference of passes
  • Door class should have a source cavern and a destination cavern to show its direction

Specifies methods required to provide system functionality. A fully documented version of the Controller is available as part of Cwk2-students .

You must NOT change this class  (except as required for Task 6 & the demonstration)).

• class Dome - a skeleton of this class is included in Cwk2-students
  • copy the code in Controller into Dome and replace ; by { } - mutators may be empty, but accessors will need to return a default value .

Your implementation should then have :

• three collections to store references to: all doors, all caverns & all passes
  • the collection of all doors should be an Arraylist where the position of the door in the ArrayList is the same as its number e. Door 0 should be in location 0 of the ArrayList
  • for ease of programming, all caverns could be a HashMap (with the name as the key)
  • passes may be stored in whatever type of collection you consider suitable

• a constructor which
  • sets the dome name from a parameter value
  • calls two private methods defined at the end of the class
    • createCavernsWithDoors - to create all the caverns in Appendix A and add them to the collection of caver In addition, create the doors between them and add to collection of doors
    • addAllPasses - to create all passes and add them to their collection
  • finally, enter all passes into the Outside cavern

• implementation for all methods in the interface Controller
• 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 (door, pass, cavern) using its key are suggested]

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 Dome

• some code has been provided, you must provide the code for other menu options
• you will need to capture input from the user (use the Scanner class not JOptionPane)
• for this task, you are only required to complete some menu options 0 – 6 . (some are done for you)
• this class should only call methods specified in Controller

You can test your code by running the DomeUI but you will eventually find this tedious. So:

• Provide a Tester class which
  • declares a variable of class Controller. Since Controller is an interface, you should then create it as an object of the Dome class (using polymorphic creation) to represent the Paradise Park
  • contains a doTest() method which calls appropriate methods on the Controller variable in a way which tests your system and demonstrates that it works according to specification. This method should include appropriate output to the terminal window. You must use comments to explain what is being test
  • Add a main() to make it runnable (see DomeUI & DomeGUI main())

Marks for this task will be awarded for:

• the appropriate choice of data,
• the sequencing of method calls
• explanations of

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 pass enters a cavern but has insufficient tokens to return to the "Outside" cavern.

The Demonstration (Task 7) will ask you to perform tasks similar to those you should perform in this class.

You should produce :

• a visually neat and readable UML-style class diagram of your system in BlueJ
• program code which is well documented, displaying both agreed standards of internal documentation and good use of the facilities available in (Controller is already well documented)

Task 6 – Additional Functionality – Challenge task  15 marks

You will only get marks for this task if you successfully complete a specific task at the demo

• Add the following methods to the Dome Uncomment their signatures in Controller
  • topUpTokens – to add tokens to a specified pass
  • moveToOutside - to move a pass directly to the Outside cavern without entering doors or losing tokens
  • convertPoints - to convert a Gold pass loyalty points to tokens (5 points = 1 token)
  • moveAll- to move all passes back to the Outside cavern

• Add code in the DomeUI class to implement the incomplete menu options 7-10 (some are already done for you)
• Add code in DomeGUI
  • add a button to find a pass and provide its functionality
  • add a menu item on the File menu to move a pass through a door and provide its functionality

The demonstration will take place after the submission date for the coursework. In a designated practical session, you will be asked to demonstrate that you have a good working knowledge of the code that you submitted. The main purpose of the demonstration is to authenticate your code by showing that you know it well enough to use it and make changes. If you do not attend the demonstration session, your assignment will get ZERO marks.

 You will be given a written specification of the tasks to be performed during the demonstration and a checklist. You will be asked to submit your demonstration to Studynet. Your demonstration as submitted to Studynet will be marked by tutors after the session using the given checklist.

The written specification of tasks will ask you to download the BlueJ project submitted as your coursework to Studynet (see below), amend some code and then re-submit the amended project also to Studynet. You will be asked to:

• to amend the Dome class to create the Paradise Park Dome with some small changes
• write a demo class with a method to test the functionality of your system as specified in the instructions
• add a new type of pass
• add code to check task 6.