Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
Summary
In this assignment, you are required to model the dotnet Hospital Management System by developing a console application using C#.
The application should have appropriate data structures to distinguish between a Doctor, Administrator and Patient as well as store the necessary links between them (such as an appointment, between a Doctor and a Patient). You are given complete control in how you create these data structures, but guidance has been given overpage.
Objects should be stored in the system and also written to .txt files such that the system can read them in and regenerate existing objects on load. This is mandatory.
Students will need to submit the complete project folder in zip format, which will have the complete C# code, solution file, data file, etc. required to run/test the program. Any special instructions required to run the code has to be provided in a text file. Submitting a lone “.exe” is not acceptable.
Assignment Objectives:
- Ensure firm understanding of the .NET framework, C# basics and C# syntax
- Understand how the .NET framework implements OO concepts and the implications this has for new language design
- Array and string manipulation
- Creating custom classes and methods in C#
- File reading, writing and manipulation in C#
- Creating interactive console applications
- Creating good OO design.
Program and data structures:
- How you structure the classes in your program is your choice. One thing you are not allowed to do is make your program fully contained inside Program.cs, or any single class.
- In the dotnet Hospital Management System, a user can log in as either a Patient, a Doctor, or an administrator. These are different roles, which would store different information, and would have a different menu. Your code structure should reflect this.
- Additionally, your code will need to generate Appointments. An appointment would need a reference to a single Doctor and a single Patient; your code structure should reflect this. You do not need to manage Dates/times for appointments (or anywhere, for that matter) in your code. This may result in appointments being difficult to distinguish and sort; you will not be marked down for this.
- Every patient, doctor and admin, has a unique ID. This ID should be an integer of reasonable length (5-8 digits). This can be randomly generated, or incremental, but it should be generated by the system on object creation, not chosen/inputted by the user.
Further recommendations:
- Objects will need to be printed out one by one, it’s recommended that each data structure has a toString() function which compresses the notable data of the class into a succinct line.
- Each role should be its own class and it should have its own MainMenu method, don’t try and create separate versions of the menu in Program.cs.
- Don’t get confused by Administrators. Doctors and Patients can’t at any stage have “admin privileges”; the administrator is a completely separate entity.
- You may find it useful to abstract common functionality into its own class, such as a FileManager class with static read and write methods or a Utils class which contains the methods to generate ID’s and filter lists.
Marking Guide
In the demos in the lab, your code needs to be compiled in Visual Studio Community edition 2022 and then the tutor will test for normal functionality as described in the descriptions above. If your code does not compile you will receive zero marks (no exceptions).
|
Task |
Items |
Max Point |
Total |
|
Console Code and Design
|
- Appropriate Headings for menus
- Basic console design
|
2 |
14 |
|
- Helpful comments
- Appropriate indenting and whitespacing
- Consistent and appropriate C# naming convention used
|
2 | ||
|
OOP principles used:
- At least 1 example of inheritance
- At least 1 example of method overloading is used
- At least 1 example of method overriding is used
- At least 1 example of constructor
- At least 1 example of extension method
- At least 1 example of garbage collection
|
6 | ||
| Appropriate use of exception handling | 5 | ||
| Low coupling, high cohesion, general code quality |
2 |
||
|
Login Menu |
Functionality including cross checking credentials with .txt file |
1.5 |
3 |
|
Password input masked in console |
1.5 |
||
|
Patient Menu |
List Patient Details |
1 |
5 |
|
List My Doctor Details |
1 |
||
|
List All Appointments |
1 |
||
|
Book Appointment, functionality including creating
Appointment object and writing to txt file
|
2 |
||
|
Doctor Menu |
List Doctor Details |
1 |
5 |
|
List Patients |
1 |
||
|
List Appointments |
1 |
||
|
Check Particular Patient |
1 |
||
|
List Appointments With Patient |
1 |
||
|
Admin Menu |
List All Doctors |
1 |
7 |
|
Check Doctor Details |
1 |
||
|
List All Patients |
1 |
||
|
Check Patient Details |
1 |
||
|
Add Doctor |
1.5 |
||
|
Add Patient |
1.5 |
||
|
Logout/Exit |
Logout functionality and Exit functionality for all 3 menus |
1 |
1 |
|
Maximum Full Marks |
35 |
||
|
Bonus Marks |
- Use of one example of anonymous method
- Use of one example of generic
- Use of one example delegates
|
3 |
5 |
|
Email functionality (e.g. confirmation of patient registration, or confirmation of booking) |
1 |
||
|
Additional user role (e.g. receptionist) |
1 |
||
Specific expected tasks and examples
1. Patient2. Doctor3. Administrator
Login Menu
Input fields:
ID and password should be checked against valid credentials inside your files. How you do this depends on how you’ve structured your classes; but any patient/doctor or admin should have a unique ID and a password. These values should be, in some way, stored in a .txt file, which your code should cross check at this screen. If entered values are not valid, display appropriate error message and allow the user to retry.
Patient Menu
All menu options MUST share this functionality (see example below):
Functionality: Lists all the fields of the currently logged in patient to the console.
Input: Key press to return to menu.
Functionality: Lists all the fields of the doctor that is registered with the currently logged in patient, to the console. It is recommended that the
Doctor data structure has a toString function which compresses the necessary details of the patient into a short line.
List All Appointments
Input: Key press to return to menu.
• Integer to select doctor (if applicable)• All necessary information to generate your Doctor data structure• Key press to return to menu.
Logout
Functionality: Returns to the login menu
Exit
Functionality: Exits the application
Doctor Menu
Input: Key press to return to menu.
List Patients
Input: Key press to return to menu.
Functionality: Lists every appointment involving the currently logged in doctor, regardless of which patient is involved, to the console, line by line. It is recommended that that the Appointment data structure has a toString function which compresses the necessary details of the appointment into a short line.
Input: Key press to return to menu.
Functionality: Prompts the user for an ID and prints the details of the patient whose ID it belongs to, to the console line by line. If there is no patient with that ID, your code should handle the error and print an appropriate error message. It is your choice whether the user is prompted to re-enter the ID or if the program returns to the Patient menu.
Input: Key press to return to menu.
List Appointments With Patient
Functionality: Prompts the user for an ID and finds the patient with that ID. Your code should then print every appointment between that patient and the currently logged in doctor. (You should not need to filter this list, as the patient should have been forced to be registered to only 1 doctor). If there is no patient with that ID, your code should handle the error and print an appropriate error message. It is your choice whether the user is prompted to re-enter the ID or if the program returns to the Patient menu.
Input: Key press to return to menu.
Functionality: Exits the application
Administrator menu
List All Doctors
Functionality: Lists a shorthand version of every doctor contained in the system to the console, line by line. It is recommended that the Doctor data structure has a toString function which compresses the necessary details of the doctor into a short line.
Input: Key press to return to menu.
Functionality: Prompts the user for an ID and prints the details of the doctor whose ID it belongs to, to the console line by line. If there is no doctor with that ID, your code should handle the error and print an appropriate error message. It is your choice whether the user is prompted to re-enter the ID or if the program returns to the Administrator menu.
Input: Key press to return to menu.
Functionality: Lists the shorthand version of every patient in the system to the console, line by line. It is recommended that the Patient data structure has a toString function which compresses the necessary details of the patient into a short line.
Input: Key press to return to menu.
Functionality: Prompts the user for an ID and prints the details of the doctor whose ID it belongs to, to the console line by line. If there is no doctor with that ID, your code should handle the error and print an appropriate error message. It is your choice whether the user is prompted to re-enter the ID or if the program returns to the Administrator menu.
Input: Key press to return to menu.
Input: Key press to return to menu.
Additional Information:
Assignment Submission
Queries
Dr. Avinash SinghRoom: CB11.07.115Phone: 9514 1825Email: [email protected]
If serious problems are discovered in assignment specification the class will be informed via an announcement on Canvas. It is your responsibility to make sure you frequently check Canvas.
PLEASE NOTE : If the answer to your questions can be found directly in any of the following
You will be directed to these locations rather than given a direct answer.
Please refer to subject outline.
Please refer to subject outline.