Oct 9, 2019

Appointment Scheduler - Java GUI or Java Project Help

Program Description

This application will allow the user to store and retrieve appointment information from a scheduler. The scheduler is (at present) very general, and could potentially be used to book an appointment for anything, e.g. logging appointments in a dentist’s office, scheduling a meeting with a boss about a project, or booking an appointment to have a muffler replaced. Regardless of the nature of the meeting, each appointment will need the following information:

1. The name of the person/client booked

2. The client’s phone number

3. The date and time of the meeting

4. (Optionally) Information about the activity involved.

In the last category, if the appointment was with a dentist, the activity could be something like “Cavity”, “New crown”, “New filling”, “Root canal”, “Cleaning and plaque removal”, etc. If it’s a meeting with your boss, the activity could be “Discuss performance evaluation”, “Progress on Project”, “Software update issues”, “Budget considerations”, etc.—the actual nature of the activity will vary depending on the context in which the scheduler is used.

In this first assignment, the Scheduler object stores an array of Appointment objects, and each appointment stores the four pieces of information indicated above. Note that we consider each appointment to be exactly 1 hour long to avoid complicating the code too much for now. Furthermore, our company is only open from 8 a.m. to 5 p.m., limiting each day to nine appointments maximum, with the last appointment starting at 4 p.m...more on this shortly. Appointments are located by looping through the Appointments array up to the last Appointment loaded, searching each appointment by its date and time until the

desired Appointment object is found. This can also be used to display a daily schedule of all appointments. But in the present version of the program, appointments cannot be deleted (yet), nor can the array be sorted (yet); these and other features will be added to the software in the next iteration of the program.

I. Load the Project, package, and classes

a. In Eclipse, add a new project called CST8284_19F_Assignment1.

To this project add a package called cst8284.asgt1.scheduler. Then, following the UML diagram below, add each of the five classes indicated to the package.

b. Before you proceed to the details of each class in Section II, note the following ‘rules’

about this assignment, which must be strictly adhered to:

i. Follow the UML diagram exactly as it is written, according to the most up-to-date version of this document. You cannot add members that are not written in the UML diagram, nor can you neglect any of them either—and this applies to features that don’t appear to have any use in your code (and on this note, be sure to see the next item). If it’s written in the UML, it’s not optional: write the code you’re directed to write, or marks will be deducted. And if you want to get creative with the requirements, feel free to do so. But do so on your own time, and do not submit your ‘improved’ version and expect to get marks for it. In short: if you hand in an assignment that differs in any way from the UML, you will lose marks.

ii. Aside from some of the getters and setters used in the smaller classes, all methods indicated in the UML are expected to be put to use in your code.

So if there’s a method that’s required in the UML and you’re not using it, you’re probably missing something, and your code is not being used correctly—and you will lose marks. Take the UML as an indication not just of what needs to be coded, but of how the code is to be connected in a well-written, optimized application (given the rather limited requirements of this assignment). So if you can’t figure out where certain features (such as the private static final constants declared in the Scheduler class) will be used in code, think first, then ask if you’re stuck: these things exist for a reason.

iii. Employ best practices at all times: reuse code, don’t copy and paste; don’t declare variables unnecessarily; keep your code to the minimum needed to ensure the program functions reliably, and avoid over coding your application; only setters and getters talk directly to private fields, everything else uses public setters and getters; chain overloaded constructors and methods. Note that this last item applies, e.g. between the

toString() method used by the Appointment class and the toString() methods used in its composite members, such as TelephoneNumber and Activity.

Additional information on the expectations for this project is included at the end of this

document under ‘III. Notes, Suggestions, Tips, and Warnings.’

II. Write the code indicated for each class

As seen in the UML diagram below, five classes will be needed in this application: Scheduler, SchedulerLauncher, Appointment, TelephoneNumber, and Activity.

Additionally, you’ll be making heavy use of Oracle’s Calendar class, which holds the date

and time of each appointment. Information on this class is available at several sites, but the following contains useful examples for those unfamiliar with this class; it’s probably the best way to get started with Calendar. See:

https://www.geeksforgeeks.org/calendar-class-in-

java-with-examples/

As always, be sure to cite any websites you used during the construction of your application. Regarding the five classes you’ll be coding: there are a few general ideas to keep in mind as you proceed (specific details on each class are included afterward). Some of these comments are most obvious from the UML diagram, but a few things can only be inferred by careful examination:

First: Only the Scheduler class handles the input and output of information. You should

not have, nor need to use, Scanner in any other class. And the same goes for outputting

Strings: only Scheduler handles I/O. Other classes than Scheduler may store String data, but all access to these Strings is made via the appropriate methods for that class,

such as toString().

Second: We assume, for now, that the user of our application is well-behaved and will not be entering any bad data—an assumption we’ll overturn in a later assignment. But at

this point, there’s no need to check the validity of the data; we’ll be doing this in the setters at some later date. Third: once you’ve instantiated a new Appointment object and saved it to the appointments array in the save appointmentsToArray() method, remember that everything goes through setters and getters from this point onward.

For example:

getAppointments[getAptIndex()].

getTelephoneNumber().toString()

returns a String version of the telephone number belonging to the Appointment object stored in the appointments array having the index value returned by getAptIndex(). (Note that ‘Apt’ is used as shorthand for ‘Appointment’ in some of the member names.) Detailed descriptions of each of the five classes used in this application follow.

a) Each instance of an Appointment class is characterized by the five properties indicated in the UML diagram for that class: the first and last name Strings; a Calendar to store the date and time of the appointment; the contactee’s telephone number; and the Activity, which can be used to store, at a minimum, a description of what the appointment is about. As indicated in the UML diagram for Appointment, you must write getters and setters for each of these five fields, the latter of which should be used when saving values in the constructors (which should, in turn, be chained).

As indicated above, note that the Appointment toString() method will need to call upon the toString()’s of Calendar, TelephoneNumber, and Activity, along with the getters for the first and last names, and use these strings to construct the string used in outputting Appointment information to the console. Aside from these features, the code for the Appointment class is straightforward, since an Appointment object mostly just holds the information; by itself, it doesn’t need to do much.

The Activity class is similarly boring; we’ll put it to better use in a later assignment. For now, just write simple getters and setters as indicated in the UML. Activity’s toString() should call on the getActivity() method to obtain its output String.

The TelephoneNumber class is slightly livelier. The components of a phone number are (1) its area code, (2) its prefix, and (3) it’s line number—roughly stated, the first, second and third fields in a String like “613-555-1212”. The constructor takes in a String in this form and parses it into its three fields, using the appropriate setters for storage. As indicated in the sample output at the end of this document, toString() should return a String in the form “(613) 555-1212”

b) SchedulerLauncher is the main point of entry for this program, hence it will contain the main() method. It has only one purpose, to launch the application by first instantiating a new Scheduler object, and then calling its launch() method—that’s all.

c) As noted above, Scheduler handles all the I/O for this application, as well as storing instantiated Appointment objects to the appointments array. The aforementioned launch() method displays the menu to the user and executes the result of the user’s selection. Note that its operation will call on two methods, displayMenu() and executeMenuItem(). This makes testing easier and has the added benefit that it will allow for a smoother transition to a GUI interface later in the semester. As indicated in the sample output below, your program should loop through inside launch() until the user selects the EXIT value to quit the application.

Note the four fixed constants

SAVE_APPOINTMENT,
DISPLAY_SCHEDULE,
DISPLAY_APPOINTMENT, and
EXIT.

These should be used in your code to ease readability, particularly in the switch() statement that determines which action to execute based on the menu presented to the user.

Appointment Scheduler - Java GUI or Java Project Help

Program Description

I. Load the Project, package, and classes

II. Write the code indicated for each class

Recent Posts

Comments