►Concurrent Programming
▼—Project Milestones
•6 — The Doctor Will See You Now
On this page:
6.1 Addressing Feedback
6.2 Vet Visits
6.3 Life as a Vet
6.4 Send your homeless tempest-tossed to me
6.5 Updated Initialization
6.6 Interfaces
8.9
    contents  ← prev  up  next → 

6 — The Doctor Will See You Now

Due Thursday, 29 February 2024, 11:59:59pm

Delivery Place the product of this week’s milestone into your git repo as follows:

Your project should generate a JAR named Milestone6.jar (see —Java, Maven; there is no need to specify a mainClass for this milestone) including the Main and EagerClientFactory classes described below. Building the project (such as with mvn package) should put the executable in a folder named target at the top level of your repo. Put the memo in the top level of your repo with the name Milestone5Feedback.md.

Purpose

The purpose of this milestone is to implement the final item of day-to-day operations, veterinary visits, and to make HALP a living entity—one whose members shift over time rather than being entirely based on an initial configuration.

6.1 Addressing Feedback

You have, or will soon, receive feedback from me on our previous milestone submission. Address each of the major points raised in the feedback. Write a memo describing each of your changes, or, if you disagree with the point being made, your explanation why.

6.2 Vet Visits

Until now, clients could schedule an appointment but appointments themselves didn’t have much meaning beyond some bits in the system. Now, we will extend the system with the notion of clients (and their pets) coming in throughout the day to see the vet that they scheduled an appointment with. Our primary concern is getting the patient and vet into an examination room at the appointed time; the examination itself will consistly simply of a single method call (see below).

Until now, the independent (concurrent) behavior in the system has arisen entirely from clients and client-initiated tasks. For vet visits to make sense, there must be another source of independent behaviors: the vets themselves. In other words, this feature will require that each vet at the clinic be capable of independent (i.e., concurrent) behavior.

Suppose a client has an appointment scheduled with a particular vet at 3:00pm. The basic sequence of events for the appointment are:

Items 1, 2, and 3 may happen in any order.

  1. The client checks in at the clinic.

  2. The vet becomes ready to see the clinic.

  3. The clock reads 3:00pm.

  4. The client and vet meet in an examination room.

  5. The clock reads 3:30pm.

  6. The client and vet leave the examination room.

Once ready, the client should wait (block) until the appointment is over.

Take careful consideration of the implications of blocking for whatever thread(s) perform the vet behavior.

Of course, things don’t always go as planned. The client may not show up on time, or at all, and likewise for the vet. The HALP clinic will be lenient, and allow both parties until the end of the alotted appointment time to show up. If the client checks in but the vet never becomes ready, the clinic notifies the client. If the client fails to check in, the vet simply goes back to their regular duties.

The notion of "failing to check in" will be based on the clock service announcing the "end time" of the appointment. For an appointment scheduled at, say, 1:00pm a client will be said to have failed to check in if the clock strikes 1:30pm without said client checking in. And similar for the vet becoming ready.

Updates to Appointment Scheduling. To simplify operations, the clinic will no longer make same-day appointments. The clinic should be mindful of the week changing. Clients will be responsible for maintaining the weeks-away information of their own appointments.

Midnight. When a new day/week begins, a client may be in the process of scheduling an appointment. Any already-selected information, like the week, should be interpreted relative to the current day/week, rather than when the selection was made. If a client has finalized the details of an appointment for the next day, but fails to actually book the appointment before the day begins, you should consider that equivalent to timing out (c.f. Dawdling Clients).

Finally, the clinic will keep a record of each appointment and its outcome: either sucessfully conducted or cancelled due to either a patient or vet no-show.

Implementation Task. Extend your ClinicEntry implementation (see Interfaces) with the following two methods:

6.3 Life as a Vet

Implement each vet in the clinic as a concurrent task(s) that operates according to the following rules:

On each day that the vet works at the clinic, at each time (c.f. Clock Service) (unless the vet is already busy):

  • If they have an appointment, they notify the clinic that they are ready. When the appointment begins—when both the patient and vet are ready and the time is between the appointment’s start (inclusive) and end (exclusive)—the vet will call the new concerns method of the corresponding ClientNotificationReceiver. You may assume that the concerns method returns eventually, without throwing an exception, but not that it returns in a particularly timely manner.

  • If they have a sufficiently long period of unbooked time—two consecutive appointment slots—they visit the shelter to give one of the unvaccinated (getVaccinated returns false) animals their shots.

  • Otherwise, they do nothing.

Of course, the vet should only be able to take a pet that isn’t being played with, and the pet will be unavailable for viewing, playing, and adopting while it is receiving its vaccination. When it returns, the pet’s getVaccinated method should report true. The vet removes the pet from the shelter at the beginning of the block of time (say, 1:00pm) and returns it at the end (in that case, 2:00pm).

6.4 Send your homeless tempest-tossed to me

With the booming success of HALP, other shelters in the region want to send their animals here to improve their chances at adoption. Implement a method on the shelter entry that brings in fresh Animals. Information about new animals will come in the form of a Reader, from which you will be able read and parse a JSON array of Animals.

Implementation Note. When a new animal arrives at the shelter, already-existing PetViewers should eventually return that animal as the result of viewNext. (Unless, of course, another client adopts them or is playing with it at an inopportune time.)

Implementation Task. Extend your ShelterEntry implementation (see Interfaces) with the importAnimals method for this purpose.

6.5 Updated Initialization

Extend your com.neu.halp.center.Main class with a method that has the following signature:

  public static CenterClientEntry initializeCenter(Reader configReader,

                                                   int clientIdleTimeoutMilliseconds,

                                                   ExecutorService threadPool

                                                   ClockService clockService) {

    ...

  }

The behavior should mimic the initialization of the previous milestone (Updated Initialization), with the provided clock service used as the source of days and times at the clinic. Try to use only gurantees of the ClockService requirements. However, if you must, you can fall back to reasoning based on your PuppetClockService implementation.

6.6 Interfaces

Place the new and updated interfaces (updated 2/24) in the designated package(s) in your project. Do not modify them.

    contents  ← prev  up  next →