Overview

A local urgent care clinic is looking for our assistance automating its case management protocols. As each patient arrives at the clinic, they are assigned (1) a five-digit case number, (2) a count of which patient number they are that day, and (3) a triage priority level of GREEN (lowest), YELLOW (middle), or RED (highest).

Higher priority patients will be seen before anyone else, but otherwise patients are served in the order they arrived.

We’ll improve upon our design for this application as the semester progresses, but for now we’ll keep things simple. In this first version of our Urgent Care case manager, you will need to:

●    Figure out where to add a new patient at a given triage level

●   Add a new patient record to the list, maintaining it as an oversize array

●    Remove the highest priority patient from the list

●   Get some summary data of the current state of the patient record list

Grading Rubric

Learning Objectives

After completing this assignment, you should be able to:

●   Comfortably implement a procedural program using static methods in Java

●   Explain the protocols used with oversize arrays

●   Verify the correctness of a static method which uses arrays by designing and implementing a boolean tester method in Java

Additional Assignment Requirements and Notes

Keep in mind:

●    Pair programming is NOT ALLOWED for this assignment. You must complete and submit P01 individually.

●   The ONLY external libraries you may use in your tester class are: java.util.Arrays

Use of any other packages (outside of java.lang) in any other classes is NOT permitted.

●   You are allowed to define any local variables you may need to implement the methods in this specification (inside methods). You are NOT allowed to define any additional instance or static variables or constants beyond those specified in the write-up.

●   All methods must be static. You are allowed to define additional private static helper methods.

●   Only the UrgentCareAdmissionsTester class may contain a main method.

●   All classes and methods must have their own Javadoc-style method header comments in accordance with the CS 300 Course Style Guide  .

●   Any source code provided in this specification may be included verbatim in your program without attribution.

●   Run your program locally before you submit to Gradescope. If it doesn’t work on your computer, it will not work on Gradescope.

Need More Help?

Check out the resources available to CS 300 students here:

https://canvas.wisc.edu/courses/344658/pages/resources

CS 300 Assignment Requirements

You are responsible for following the requirements listed on both of these pages on all CS 300 assignments, whether you’ve read them recently or not. Take a moment to review them if it’s been a while:

●   Academic Conduct Expectations and Advice, which addresses such questions as:

○    How much can you talk to your classmates?

○    How much can you look up on the internet?

○   What do I do about hardware problems?

○   and more!

●   Course Style Guide, which addresses such questions as:

○   What should my source code look like?

○    How much should I comment?

○   and more!

Getting Started

1.   Create a new project in Eclipse, called something like P01 Urgent Care.

a.    Ensure this project uses Java 17. Select “JavaSE-17” under “Use an execution environment JRE” in the New Java Project dialog box.

b.    Do not create a project-specific package; use the default package.

2.    Download (1) Java source file from the assignment page on Canvas:

a.    UrgentCareAdmissionsTester.java (includes a main method)

3.    Create one (1) Java source files within that project’s src folder:

a.    UrgentCareAdmissions.java (does NOT include a main method)

All methods in this program will be static methods, as this program focuses on procedural programming.

Implementation Requirements Overview

Your UrgentCareAdmissions.java program must contain the following methods, described in detail on this javadoc page.

●   public static int getAdmissionIndex(int triage, int[][] patientsList, int size)

●   public static int addPatient(int[] patientRecord, int index, int[][] patientsList, int size)

●   public static int removeNextPatient(int[][] patientsList, int size)

●   public static int getPatientIndex(int caseID, int[][] patientsList, int size)

●   public static int getLongestWaitingPatientIndex(int[][] patientsList, int size)

●   public static String getSummary(int[][] patientsList, int size)

You must also add three public static final int values: RED, YELLOW, and GREEN. You may choose any values for these three constants, as long as RED < YELLOW < GREEN is true. I suggest 0, 1, and 2    respectively (for simplicity).

An Aside: Using Javadocs to build a program

The Javadoc page linked above is automatically generated by the IDE, using the contents of Javadoc-style comments in the program source code. When creating this assignment, I wrote UrgentCareAdmissions    with comments for the class (a “class header” comment) and each method (a “method header” comment) in the following style:

/**

* Removes the patient record at index 0 of the patientsList, if there

* is one, and updates the rest of the list to maintain the oversize

* array in its current ordering.

*

* @param patientsList the current, active list of patient records

* @param size the number of patients currently in the list

* @return the number of patients in patientsList after this method has

*   finished running

*/

Both class and method header comments begin with a /** (two asterisks) and end with a */ – note that if you only use one asterisk at the beginning, this creates a multiline comment, not a Javadoc comment.

This is important documentation, and you will be required to do the same for all classes and methods you write in this course. You are welcome to use any text from the writeups, verbatim, in your comments. You are not required to generate HTML javadoc pages, but you can if you want to!

At the top of the javadoc page you will find a summary of the data fields and methods in the class, and if you either click on their names or scroll down, you will find the full detailed description of what these     methods are supposed to do, what parameters they expect, and what they should return.

Most – if not all – of our programming assignments this semester will use these generated Javadoc pages to communicate the requirements of the assignment to you, so if you have any questions about how to   use them, this is the time to ask.

Beginning the program

Add the methods listed in the Javadoc as stub methods – methods containing only a default return statement – to your class file, and then turn to the tester file before you go any further.

A link to the UrgentCareAdmissionsTester.java starter file can be found on the assignment page, so we   haven’t provided a Javadoc file for it. One test method, testGetIndex(), has been provided for you in its entirety; the others include comments with suggestions for the scenarios you should test to ensure    that your implementation is working correctly. Be aware that these other comments are NOT in Javadoc style yet – you’ll need to convert them to that style yourself before submitting if you’d like full credit.

We strongly recommend that you implement at least one scenario in each tester method FIRST, to help understand the desired functionality of the utility methods in UrgentCareAdmissions.

Implementation Details and Suggestions

For this iteration of the urgent care admissions program, we will assume that the data is stored in arrays created by and stored in an external main class (for you, the tester class). Your implementation will use  these arrays as provided, and you can assume that they are correctly formatted.

Getting the correct index

Begin by adding the getAdmissionIndex() method as a stub method:

public static int getAdmissionIndex(int triage, int[][] patientsList,

int size) {

return -1;

}

In a stub method, you include a return statement with some dummy value to satisfy the compiler, which expects this method to return an integer.

Before going any further with this implementation, check out the testGetIndex() method in the tester class. We’ve provided it for you in its entirety.

All test methods you write this semester will look something like this (this is a stub version):

/**

* Checks whether method() works as expected

* @return true if method functionality is verified, false otherwise

*/

public static boolean testMethod() { return false; }

Note there are NO parameters, the method is STATIC, and it returns a  BOOLEAN value.

At the beginning of the semester, we’ll suggest scenarios for you to test. The testGetIndex() method tests three (3):

1.   Adding a patient with a HIGHER triage priority than any currently present in the array. To do this, we create an array with no RED priority patients and get the index to add a RED  priority  patient. We expect this to be 0, so if we get any other value, the test fails.

2.   Adding a patient with a LOWER triage priority than any currently present in the array. To do this, we create an array with no GREEN priority patients and get the index to add a GREEN      priority patient. We expect this to be the current size of the oversize array, so if we get any  other value, the test fails.

3.   Adding a patient with the SAME triage priority as existing patients. New patients at the same    priority should be added AFTER any existing patients. We test this for all three triage levels on an array containing patients at all three levels; all of these will have different expected values.

A common trap when writing tests is to make the test as complex (if not moreso) than the code it tests, which leads to Even More Bugs and development time. Keep your tests simple! Many times it’s just a    matter of constructing an input and then comparing the output of the method to an expected value.

You’ll want to cover as many scenarios as you can think of:

●    Inputs: empty arrays, partially-filled arrays, completely-filled arrays, one full one empty, etc.

●   Outputs: situations where the method runs normally, where it finds an error, etc.

Before you begin implementing, read the description of the getAdmissionIndex() method again and think about what potential scenario(s) we HAVEN’T covered in this test method. There is at least one very important one. Talk to your classmates if you need to, and write it down.

STOP. No really. Write it down.

Was it “input: give the method a FULL oversize array”? Because none of the scenarios we provided test the second part of the return value statement:

Returns:

the index at which the patient should be inserted into the list, or -1 if the list is full

We’ve created a separate tester method for this, testEmptyAndFullArrays() (test method names can get a little long, it’s fine). Before you continue, implement the scenarios in that method related to  getAdmissionIndex() and change the return statement so that if all of your tests pass, the method returns true. (Don’t worry about the other scenarios for now; you can return to this method later.)

You’re welcome to add print statements when certain tests fail – it can be useful to know where and how things went differently to what you expected.

PRO TIP: when you encounter a problem or question about your code, design and then implement a test method to verify your understanding of what IS happening versus what SHOULD be happening. Share      the test and its results with course staff, and they can help you much more efficiently.

Cool – you have tester methods now! Time to start implementing getAdmissionIndex() and run the tester class to see if it works. If you’re successful, the “get index” and “empty/full” tests should return    true, but the others should still be false.

Now draw the rest of the owl1

Using the previous section as a guide and the Javadoc page as a reference, implement at least one test scenario for each method and then implement the method itself. (Ideally, implement the entire test     method first.)

We’ve provided some sample patient records in the tester file, which you’re welcome to reuse or modify as you see fit in your own tests. Your methods can assume that the input array is set up correctly (all RED level patients first, then YELLOWs, then GREENs), so your test methods should provide arrays that follow those rules.

For the getSummary() method, we’ve provided a sample output in the Javadoc, but here are a couple more. Note that there is a newline character ('\n') at the end of each line, including the last one!

Reference: Valid Patient Lists

For reference, here are some examples of valid Nx3 patient lists. Note that all values outside of the index range 0 to (size-1) are set to null, and all null values must be at the END of the patientsList array.

This list has length 8 but size 5, and contains 1 RED, 3 YELLOW, and 1 GREEN patient record with room for 3 more patient records:

{ {32702, 3, UrgentCareAdmissions.RED},

{21801, 2, UrgentCareAdmissions.YELLOW},

{22002, 4, UrgentCareAdmissions.YELLOW},

{11901, 5, UrgentCareAdmissions.YELLOW},

{31501, 1, UrgentCareAdmissions.GREEN},

null, null, null

}

This list has length 8 but size 0, and is what we’d call “empty”:

{ null, null, null, null, null, null, null, null }

This list has length 5 and size 5, and contains 1 RED, 3 YELLOW, and 1 GREEN patient record with NO room for more, and is what we’d call “full” (size == length, contains no null values):

{ {32702, 3, UrgentCareAdmissions.RED},

{21801, 2, UrgentCareAdmissions.YELLOW},

{22002, 4, UrgentCareAdmissions.YELLOW},

{11901, 5, UrgentCareAdmissions.YELLOW},

{31501, 1, UrgentCareAdmissions.GREEN}

}

Note that while the initialized contents and sizes of the first and third lists are the same, they are NOT considered equal by Arrays.deepEquals() because they have different lengths.

Additionally, a valid patientsList need not have patients at all triage levels. This list has all YELLOW patients, with length 8 and size 3:

{ {21801, 2, UrgentCareAdmissions.YELLOW},

{22002, 3, UrgentCareAdmissions.YELLOW},

{11901, 4, UrgentCareAdmissions.YELLOW},

null, null, null, null, null

}

Any RED patient records would be added at the front of this list, and any GREEN would be added at the end.