FunIT Online Java Documentation powered by GitHub Pages
FunIT is a new theme park that provides fun rides for both young and old. The executives of FunIT has decided that they need to implement a system to track all payment transactions and to enforce business rules. You are the software engineer employed to create this new application.
- You are expected to do your entire assignment on your own, otherwise, you will be penalized.
- You must build a command-line interface (CLI) to your application as opposed to a graphical-user interface (GUI). A command-line interface application does not make use of dialogue boxes to communicate with the user. Instead, it displays its output in the same window in which you have issued the "execute" or "run" command to run your application and it takes its input from the keyboard. In most of our assignments, your application will need to be "menu-driven", i.e., the execution of your application is driven by the menu selection the user has made (from menus displayed on the monitor console).
- You must use validate any input that the user keys and prevent any erroneous and exceptional (i.e., unexpected situations) input that may cause your system to crash that may occur.
- You cannot use any libraries aside from the libraries that comes with standard Java.
- Do not "hardcode" any values into your code. Instead, ask the user to enter this information. This makes your application more flexible.
- You must not create Java packages. You must not create Jar files. You must not create additional classes. You must have all your java files in one directory.
| Front Menu |
Display the following options to staff
Quit from application when user enters -99. Upon quitting, display entire day's transactions. |
|||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Add ride players |
|
|||||||||||||||||||||||||||
| Calculation of final price of ride |
The price of the ride for each player is stated in the table below.
For each of the above discounts, display to the staff the appropriate input / menu and await their input so that the correct discount can be applied to the final price. After the final price has been calculated, a final 7% GST must be applied. When the staff keys in -99, cancel the adding of player(s) process. |
|||||||||||||||||||||||||||
| Ride |
As the current ride only allow 1 adult and 1 child ONLY. After a player has made full payment, the staff will not be able to add another player until the ride has started. Display the player's name(s) after the ride. |
| Daily Transactions |
Display all the transactions since the start of the day. Each transaction should hold the name of the players, final cost and number of players for each ride is being display. Trigger:
|
|---|---|
| Ride |
Additional of 5 players per ride. After the 5 slots has been take up, the staff will not be able to add another player until the ride has started. Display the list of players that was added into the ride after it has started |
Marks will be deducted for lack of documentation or over-commenting. Some guidelines are stated below.
The proper way to create a function is to first write a header comment, then perhaps a stub, and finally the code.
Each function (this includes "main") must have a header comment containing a short description of what the function is supposed to accomplish. In order to competently tell what the function does, these "headers" must say what the inputs and outputs are.
The header comment of a function must contain the names of the parameters of the function (if any), plus explanations of what kind of data they are supposed to contain. It must explain what the function accomplishes with these objects.
The idea is to tell enough about the function so that people will be able to figure out how to use the function based on your information. You must include enough detail in your headers to get the main idea across, but no more detail than is necessary.
The beginning of the header for the function "main" must contain your name, your admin number, the course name, and the date the writing of the program was started and completed. Each of these things must be clearly labeled.
The header of any function besides "main" must give the names of all its callers (the subprograms that call it) and the names of all its callees (the subprograms it calls), All names of constants, types, variables, functions, etc. must be "self-documenting" and "selfdescribing.". For example, you should call a variable a name such as "total" if it is used to store a total. Call a function a name like "printList" if its job is to print a list. If you are able to name a particular constant, type, or variable so well that it becomes abundantly clear from its name alone what it is used for, then it may not need any further documentation. Otherwise, you must explain its use with "in-line" documentation next to its declaration.
The decision whether to make other in-line comments is left up to you. However, in-line comments are only needed occasionally in programs that have good headers, good naming conventions, and good organization. "Good form", which is one of the criteria upon which your program is graded, demands that you avoid over-commenting, as well as undercommenting.
For example, the program line:
Sum = 0 ; /* We initialize the value of the sum to zero */illustrates blatant over-commenting. The comment inserted to the right of the statement does not add anything to our understanding of what the statement does.
The statement
Sum = 0 ;alone tells us just as much.
Don’t place all your codes into the main method. You will be assessed on how your usage of methods to reduce repeated codes in your application.