STARS: Resort Management System for Space Recreation.

STARS Project: Resort Management System for Space Travel and Recreation Facilities

Introduction to the STARS Project

In a galaxy far away, the STAR organisation manages a number of resorts offering space travel and recreation facilities. These resorts always consist of a number of worlds offering different leisure facilities. Each world is connected by shuttles to some of the other worlds of the resort. A card must be used to make a shuttle to journey to another world. Credits can be bought for cards and these are used when making a shuttle journey. However, there are a number of conditions which need to be met before anyone (card) can use a card for a shuttle journey.

Recently, a number of incidents have occurred, which have convinced STAR that they need a better control system: someone who needed to be contacted urgently could not be located, a number of people were able to shuttle to worlds to which they were not entitled, and the Health & Safety Council has expressed concerns about STAR’s ability to ensure peoples’ safety in the event of a major incident. This project will initially be implemented at the Wayward Asteroids Resort (and then rolled out to other resorts).

System Requirements

People will be tracked using their cards

1. The following basic functional requirements have been established for the proposed system:

Display details of the whole resort
List all cards on each world of the resort
List all cards currently on a specified world
Find the current location of a card
Authorise a shuttle journey, if it meets the required conditions
Top up a card’s credits

2. The followingdata requirements have been established:

Card– used by people at the resort for travel.

Information stored about a card includes: a card ID number, name, a luxury rating and a number of credits.

The Card class constructor uses parameters to set the card id, the name, the luxury rating and the number of credits. The luxury rating (1 to 10) determines the worlds which the person is allowed to visit e.g. a card with a rating of 3 is allowed to visit to all worlds rated 3 or below.

When a card is used to make a journey by shuttle a basic 4 credits is deducted. as people enter the shuttle. For some special types of cards this charge may vary (more later). People may top up their credits at any time. (Handling the actual payments is outside the scope of this project)

World – a resort has a network of worlds

Each world has a reference number, a name, a rating and a capacity (the maximum number of people/cards that can be on the world at any one time). Each world should maintain a list of all cards currently on that world. These lists should be updated whenever a card enters or leaves a world, so that it is always possible to say who is currently on a world and to find the location of a person as specified by their card

System Requirements for the STARS Project

Shuttle– connects two worlds at the resort

Each shuttle has a journey code and connects a source world to a destination world. It represents a journey in one direction only. To make a shuttle journey, certain conditions must be met. If these conditions are met, the system allows the person onto the shuttle to travel to the destination world. It updates its records to show that a card has left the source world and has travelled to the destination world. It also updates the card's credits and other information, as appropriate.

A request by someone(card) to make a shuttle journey will produce one of the following results:

Refusal to enter the shuttle, because :
the card's luxury rating is lower than the rating of the destination world.
the arrival of the card would exceed the maximum capacity of the destination world.
the card does not have enough credits for the journey
the card is not listed in the source world for the shuttle

These conditions can be handled by the Shuttle, calling methods in Card, or World classes

Successful entry, because none of the above conditions is true

Resort - implements the STARS interface

Each resort has a network of worlds joined by one-way shuttles. It also has a collection of cards

A resort must always have a “Home” world which stores all cards. Its name MUST be "Home" and it MUST have a rating of 0 and a large maximum capacity. All cards registered at a resort are initially added to this “Home” world.

You should assume that in this initial version of the system, credits are only used to cover the costs of shuttle journeys. A card arriving or leaving the resort is also outside the scope of this assignment.

Paired Programming- this assignment may be done Individually or optionally in Pairs

You may do this assignment either individually, or in a pair. You may select your own partner.
For paired programming to be successful, members must be able to discuss and work together, for suitably long periods of time. You must, therefore, identify time slots in which you can both work together. During your session together, you should vary who actually types in the code and who is observing/advising to ensure an even distribution of work. Screen sharing is a useful tool.
Paired programming works best if the skill levels of the pair are roughly equivalent. If there is a wide disparity between skill levels, there is a high probability that the weaker of the pair will not learn anything, while the stronger will do all of the work. This will not prepare the weaker partner for future assessments.
Partners do not have to attend the same practicals, as practical sessions should NOT be used to complete this assignment (but you may use them to get to get help).
Partners must EACH submit the same project file to Studynet by the deadline.

Produce a BlueJ project implementing a version of STARS by completing tasks described below. Your project must be capable of running correctly on the software used in UH labs.

Your STARS 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.
Marks shown for each task include marks for both functionality and design.
Your project must compile. Code which does not compile may be included as comments
You must attend the demonstration session. If you do not attend your designated demonstration session, you will get ZERO marks.

Marks awarded for tasks below total 120. Your mark will be then converted to a %

class Cardshould have, at least:

the fields described above
a constructor to set all fields values, either using parameter values, or default values (see above)
accessors to return the Card id, the luxury rating, number of credits
methods to add or deduct credits
a method returning boolean True,if the card has enough credits for a shuttle journey
a toString()method returning a String with all relevant information about the Card

You may add further methods, if you consider them useful

class CardTester- which can be run to show that the Card class works properly. It should:

create some suitable Card objects
and call their methods
show that actual results are as expected

class Worldshould include:

suitable fields as specified above.
a constructor to create a world using suitable parameters
accessors to return its world number, name, luxury rating
an ArrayListfield to store Card object references.. (declared and created)
mutator ; enter()which has a Cardas a parameter and adds it from the ArrayList
mutator leave()which has a Card as a parameter, finds its position in the ArrayListand then removes using position.
an accessor which either says whether the world is full (reached capacity) (..or still has capacity)
method to list all the Cards currently on the world
methods to find and return details of one Card on the world
an accessor which returns a boolean saying whether a Card is in the world (in the ArrayList)
a toString() method which includes world details and a list of the Cards in the world

This is a basic list of methods and you may add more if you require them. You should NOT have mutators which change the basic information about a world ( reference number, name, luxury rating as these should not change)

classShuttle should include:

suitable fields as specified above. The "from" world and the "to" world should be World objects

a small range of accessors/mutators to process data held by the class

method which returns a boolean saying whether a card given as a parameter can enter the shuttle

Functional and Data Requirements

a method to process a card moving to the destination world;

if the card meets the conditions, remove it from the source world, add it to the destination world, update information on the card, and returna suitable message

if it does not meet one of the conditions, returnan appropriate message and do NOT move it

a method toString()which returns a Stringrepresentation of an object of that class (no need to list all of the world details, just the world numbers and names)

Without these classes you will find it difficult to develop the remaining classes. You may add further fields/methods to these classes if you require them during further development

class Resort - provides all of the basic functionality for this application.

This class implements the STARS interface. If you are unable to provide a full implementation of STARS in your Resort class, comment out unimplemented methods of STARS, so that Resort compiles

You must NOT change the signatures of any methods in the STARS interface - you will be penalised

Implementing the STARS interface

We have prepared this for you by copying the methods specified in the interface and replacing the ; with "stubs" where you can write your code.

In Resort, you are expected to declared fields and add the code for the methods listed.
The "stubs for the accessors currently return default values; you should replace these with relevant returns
You may add any further methods you consider necessary, BUT these additional methods must have the modifier private, so they cannot be used in client classes
Most of the methods in this class should call/invoke methods on objects of the lower classes
Methods should NOT deal with any input/output, but use parameters and return value
The largest portion of marks in this task are for the methods: canTravel()and travel()

Fields:

Resort location set by a parameter in the constructor
ArrayLists of all cards, all worlds and all shuttles (3 ArrayLists)
In the Arraylistof worlds, “Home” world should always be at ArrayList location 0.
[Note: for all shuttles, you may use a HashMap instead of an ArrayList]

Constructor:- should create a resort located in the Wayward Asteroids as given in the Appendix below

should have a parameter to set the resort location
should call/invokethe three private methods defined at the end of the class to implement the Wayward Resort described in Appendix A (below)
loadCards- should create all cards and add them to their collection
loadWorlds- should create all the worlds and add them to their collection in the order of their reference numbers.
setUpShuttles– should create all shuttles and add them to their collection
All cards should be added to the “Home” world

travel()and canTravel() carry the majority of marks in this task. They should return an appropriate message for the outcome. They should include a message if either the card or the shuttle are NOT part of the resort.

Helpful methods

[3 private methods at the end of this class , to find and return each type of object (shuttle, pass, world) from its collection using key data, may be useful, but not required]

class ResortUI- this is the class which provides an application for the user
only ResortUIand the MyTester in Task 5 should use out.println
this is the only class which has input and output from/to the user
some of the code has been written for you
you should provide the remaining code as shown by the comments
this class should only call methods specified in STARS
it should compile (but not work) even if you have not yet written the implementation for Resort

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

Write the MyTesterclass which declares a variable of class STARS. Since STARS is an interface, you should then create it as an object of the Resort class (using polymorphic creation) to represent the Wayward Asteroids
doTest()method in MyTester calls appropriate methods on the Resort variable in a way which tests this class and demonstrates that it works according to specification. This method should include appropriate output to the terminal window. Use comments to explain what is being tested.

Other than MyTesterand CardTester, you are NOT required to write testers for the other classes

Marks for this task will be awarded for:

the appropriate choice of data,
the sequencing of method calls
appropriate output
explanations 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.

You should produce:

a visually neat and readable UML-style class diagram of your system as a screenshot from BlueJ

program code should be well documented, displaying agreed standards of internal documentation and naming conventions. No need for detailed comments on method code (Resort is well documented)

Provide the following subclasses which extend the Card class.

All should have a toString() method which overrides toString() in Card to include subclass data

Tourist card:

is created with a specified luxury rating and a number of credits determined by parameter values
deduct 4 credits whenever a shuttle journey is made
citizenship (planet they come from) needs to be specified

Business card

are created with a luxury rating, 30 credits and 20 loyalty points
deduct only 3 credits and add 2 loyalty points whenever a shuttle journey is made
loyalty points can be converted into credits (5 loyalty points = 1 credit)

Staff card

are created with the highest luxury rating of 10 (staff can visit all worlds) and 0 credits
include an employee number, a job description, a journey score
deduct 0 credits, but add 1 to the journey score whenever a shuttle journey is made

After the assignment hand-in, you will be asked to access your submitted assignment and a written demo specification. In a timed slot of 1 hour 50 mins, you will be asked to make specified changes and upload your amended code to the Demo Assignment slot. 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: