210CT Hospital Staffing System

Description

In this coursework you are asked to implement parts of an application that handles, sorts and searches a collection of Medical Staff (Doctors) records for a Hospital Staffing System. Most of the application is already written (see Appendix and downloadable on Moodle), including:

• A FileHandler class that loads and saves doctor records from/to a text file.
• A DoctorFactory class that creates Doctor and DoctorList objects. 
• The Doctor and DoctorList interfaces. 
• A HospitalStaffingSys class that runs the application using a menu. 

The above classes and interfaces must be used unmodified. The parts of the application you need to implement are in two phases.

Phase 1: you need to draw a UML class diagram with association for the application and implement the Abstract Data Type (ADT) classes:

• A class to implement the DoctorList interface, called MyDoctorList
• A class to implement the Doctor interface, called MyDoctor

Within those classes, or in additional “helper” classes, the functionality of the application: o The basic operations of the collection classes (e.g. add, remove, iteration)

• Sorting doctors by national insurance number, by year of starting job, by salary and by department code.
• Searching for a doctor by national insurance number.
• Easy printing via toString() methods for displaying name, national insurance number, year of starting job, salary and full department name referenced by department codes from text file include.
• “near match” (see below)

When sorting, the number of comparisons performed must be reported to the user.

The “near match” feature

This feature is required if you work on the assignment in pairs, but is optional if you work individually. It implements the ability to check whether a particular doctor object fits a description “approximately”. The relevant method is already present in the Doctor interface:

public boolean match(String name, int startYear, int salary)

The name parameter is ignored if null or empty, while the year and salary parameters are ignored if ≤ 0. If all three parameters are ignored the method returns false, otherwise it returns true if the doctor gives a “near match” with the non-ignored parameter values. A “near match” is defined as start year ± 1, salary ± £5000 and a substring-match of name (e.g. “Mar” would match “Dr Mary Smith” and “Dr Mark Jones”). Here is a fuller example:

match(“”, 2010, 35000) would near-match a doctor who started 2009-2011 with a salary of £30000-40000

Phase 2: you need to apply the MVC pattern to improve the application architecture for better OO features, requiring you to create additional classes that replace the HospitalStaffingSys class:

• A HosSystemIO class that handles all input and output.
• A HosSystemController class that controls interactions between user and the program. 
• A HosSystemPro class that defines one method only – the main() method, which should be very short, say two lines only, to run the application in the same way. 

You need to modify your UML class diagram in phase 1 to reflect the above improvement. You do not have to change any other classes. The application should provide the same menu and functionality.

Your tasks

You must design, implement, test and document adequately the Hospital Staffing System. Firstly complete Phase 1 and make sure that the application is working correctly before attempting Phase 2.

• Design   You must produce a UML Class Diagram with associations that shows all classes with full details. You may use any Java collection classes you like (ArrayList, LinkedList, HashMap, etc), or use an ordinary array, or create your own data structure from scratch if you prefer. You will need to describe your design in words. If you write your own search or sort algorithm then this should be documented in pseudocode.
• Implementation   Your code should fully reflect the design and be well laid out (indented) and internally documented with ordinary comments as well as Javadoc comments.
• Testing   You must produce a test plan that identifies all implemented functionality, test data and the expected outcomes. All implemented functionality should be tested according to your test plan, and evidence of run be provided to show at least a convincing subset of the testing performed. 