You have been tasked with creating a program that models the diagnosing and subsequent curing of medical patients – Disease & Cure Administration (DCA). Let’s jump right into it.

Main concepts

The system revolves around a number of actors:

  • Patient: this represents someone in need of medical assistance.
  • Disease: this represents some ailment one or more patients may suffer from.
  • Symptom: the disease features one or more symptoms. By examining what symptoms the patient exhibits, it is possible to pinpoint the specific disease the patient suffers from.
  • Doctor: the doctor is responsible for diagnosing the patient’s disease and appropriate cure.
  • Cure: this represents a remedy to bring the patient’s health back to normal and remove any symptoms he/she may exhibit.

A typical flow in a session

Your application should support a procedure like the one described below:

  • A patient enters the clinic, suffering from one or more symptoms and having a health lower than 100%.
  • The doctor diagnoses the patient, examining the symptoms the patient exhibits and comparing these to the symptoms of any known diseases.
  • If a match is found, the doctor provides the patient with the cure. This may be distributed in several different ways, for instance as pills to be taken orally or in syringes to be injected into the patient’s body.
  • The patient uses the cure a number of times. Every time the cure is administered, the patient’s health increases until it reaches 100% again. When this happens, all the patient’s symptoms disappear.
  • The patient is now cured.

Specific requirements to implementation

About the patients:

Abstract: A patient is defined by a name, a number describing his/her overall health (0-100%) and one or more symptoms. A patient with no symptoms should be at 100% health; correspondingly, a patient with any symptoms should have less than 100% health. It should be possible to heal the patient, and thus increasing his/her health. If the patient is restored to 100% health, he/she is relieved of all symptoms. A patient can never have above 100% health.

Implementation: You should provide a Patient class with fields as described above (name, health and symptoms) that honor the constraints listed as well as a heal method that can be called when curing the patient. Healing the patient should bring his/her health towards 100% and eventually remove any symptoms associated with the patient.

About the symptoms:

Abstract: A symptom is defined by a name and a severity level; the latter could be, for instance, “trivial”, “serious” or “life-threatening”. All symptoms are put in a file that can be read from disk; at application start, the symptoms are read from the disk and loaded into a registry. This registry makes it possible to access data about all known symptoms at any time.

Implementation: You should provide two classes: a Symptom class and a SymptomRegistry class. The Symptom class should include the fields described above (name and severity level). The SymptomRegistry class should load a list of symptoms from a text file (either by itself or through a helper class) and provide a way to retrieve one or all symptoms at once.

Example of contents of the text file: See image.

About the diseases:

Abstract: A disease is defined by a name, a number of symptoms and a reference to the cure required to remove the condition from the patient. As with the symptoms, a registry provides easy access to all known diseases. The registry can also load the disease information from disk; however, it is not mandatory – it is OK if the disease information is created when the registry is initialized.

Implementation: You should provide two classes: a Disease class and a DiseaseRegistry class. The Disease class should include the fields described above (name, list of symptoms and cure). In a perfect world, there are no diseases that cannot be cured, so we assume that a cure will be available for any disease. The DiseaseRegistry should, as with the SymptomRegistry, provide a way to access one or all symptoms currently in the registry. You may, as with the SymptomRegistry, initialize it with a text file – this is however not mandatory (but otherwise, you should provide a way to easily add new diseases to the registry on-the- fly). Provide some test data in the form of a few diseases, complete with related symptoms.

About the doctor:

Abstract: The doctor diagnoses the patient and suggests a cure. The diagnosis follows the below algorithm:

  • Only diseases that include ALL the symptoms the patient exhibits are considered possible matches. Thus, a list is made of all diseases that at the very least include every single symptom the patient experiences. A disease may feature additional symptoms that the patient perhaps hasn’t experienced yet, though.
  • If no diseases are found, no cure is returned.
  • If exactly one disease is found, the cure corresponding to that disease is returned.
  • If more than one disease is found, the cure for the disease with the fewest additional symptoms is returned. If more than one disease has the lowest number of additional symptoms of all the found diseases, the cure for the first of these is returned.

Implementation: You should provide a Doctor class with only one method (which might as well be static, since the doctor class contains no state). The method, diagnose, performs a diagnosis as described in the algorithm above. For the sake of simplicity, we assume that a patient is only suffering from a single disease at any given time.

About the cures:

Abstract: A cure is defined by a name and a health factor, the latter defining how many percent of health the cure heals the patient every time the cure is administered. Cures come in different fashions; examples are cures that are distributed in pill form and cures that are injected into the bloodstream. While these cures differ in the way they are administered, they work toward the same purpose: to bring the patient’s health up to 100% and eventually relieve him/her of any symptoms.

Implementation: You should provide a Cure class which serves as a superclass to any specific cure types. This class should have fields as described above (name and health factor) that can be used by the child classes, as well as an method for administering the cure, administer, which should be designed to be overridden by the child classes. The method takes a patient as parameter and subsequently calls that patient’s heal method with the cure’s health factor as a parameter. You should provide at least two child classes that represent different types of cure (e.g. PillBasedCure, InjectedCure) and each expose their own method of administering the cure (takePills, inject etc.). These methods should be called from the child classes’ overridden administer method.

Tips

  • Use good object oriented practices. This includes, as you know, inheritance, encapsulation and polymorphism where applicable.
  • Use constructors with parameters for quick object creation where it makes sense. For instance, a patient should be created with a degraded health factor and some symptoms immediately.
  • Override toString and equals methods as necessary. Especially for symptoms it might make very good sense to provide your own implementation of the equals method.

Testing

When the system is ready, you should provide a test class with a main method to see if your system works the way it’s supposed to. At the bare minimum, test in this class that you can:

  • Load symptoms from file to registry and access them from the registry
  • Add new diseases to registry (or load them from file) and access them from the registry
  • Create new patients with various symptoms and levels of health
  • Diagnose patients – make sure to test different aspects of the diagnosis algorithm (e.g. with both one and multiple possible cures)
  • Administer different types of cures to patients until they are completely cured, and confirm that their symptoms are gone, too

Diagram

The below class diagram may be helpful for you in your implementation: See image.

Academic Honesty!
It is not our intention to break the school's academic policy. Projects posted are only used as a reference and should not be submitted as is. We are not held liable for any misuse of the solutions. Please see the frequently asked questions page for further questions and inquiries.
Kindly fill out the form. Please provide a valid email address and we'll get back to you in less than 24 hours. We will be sending an invoice through PayPal upon confirmation. We are a non profit organization however we need an amount to keep this organization running, and to be able to complete our research and development.