CS225_SP22_Group_D7
05-22-2022
Here is our group's C++ project, the Computing Assignment 2 of CS225. It analogs a simplified hospital registration system using key structures like double linked-list, Fibonacci heap, B tree, B+ tree, and Hash table.
Wang Jie - ZJU-UIUC Institute
Hong Jiadong - ZJU-UIUC Institute
Cai Yitao - ZJU-UIUC Institute
Yang Peidong - ZJU-UIUC Institute
As shown in the figure below, the input testcase is consist of a series of documents named after "DataXX.csv", where XX ranges from 01 to 15.
All input data are generated by onlinedatagenerator.com, with some improvement. Based on real databases and are highly creditable.
Our project is highly comprehensive and virtual.
As shown in the picture below, we take the registry station as
需要画图
Here is the program GUI, which has 9 major operation and more sub-modification function. The operation and control flow is presented in the following picture.
==========================================
>> Main menu <<
------------------------------------------
[1] Time step forward for half day
[2] Set up registry information
[3] Set up hospital information
[4] Withdraw a record with id
[5] Modify a record information with id
[6] Print all the records that have been rescued.
[7] Filter records
[9] Quit the program
------------------------------------------
May.30, 2022 14:13
==========================================
Our SQL database realize the functionality of
flowchart LR;
s1((start)) --> set_up(Initialize data structure and values)
set_up --> main(print main menu and choose work flow)
%%subgraph H[exit program]
%% direction LR;
del(delete all structures) --> exit((exit))
%%end
main--1-->A[half-daily simulation]
main--2-->B[registry menu]
main--3-->C[hospital menu]
main--4-->D[withdraw]
main--5-->E[modify]
main--6-->F(print all records)
main--7-->G[print filtered records]
main--9-->del
A --> back(back to main menu)
B --> back
C --> back
D --> back
E --> back
F --> back
G --> back
back -..-> main
flowchart TB;
subgraph G[print filtered records]
direction TB;
pin(get filter information) --> pfind(hash find eligible node)
pfind --> pprint(traverse to print the records)
end
subgraph B[registry menu]
direction LR;
reg_key{{option}} --1--> reg1(modify registry capacity)
reg_key --2--> reg2(show registry information)
reg_key --9--> reg9(back to main)
reg1 --> end_reg((end))
reg2 --> end_reg
reg9 --> end_reg
end
subgraph C[hospital menu]
direction LR;
hos_key{{option}} --1--> hos1(modify hospital capacity)
hos_key --2--> hos2(show hospital information)
hos_key --9--> hos9(back to main)
hos1 --> end_hos((end))
hos2 --> end_hos
hos9 --> end_hos
end
flowchart TB;
subgraph E[modify]
direction TB;
modid(get modify infomation) --> modfind(find record with id)
modfind --> modmod(modify record data)
modmod --> modmove(move node if necessary)
modmove --> modcalcp(calculate primary number)
modcalcp --> modheap(consolidate the heap)
end
subgraph D[withdraw]
direction TB;
wid(get withdraw record id) --> wfind(find node with that id)
wfind --> wdel(delete node from original structure)
wdel --> wmove(move the node to withdraw list)
wmove --> wreset(reset node status data)
end
subgraph A[half-daily simulation]
direction TB;
m1(read data from files) --> m2(send data to registry lists)
m2 --> m3(copy new records to heaps structure)
m3 --> m4(transport eligible records in heaps structure)
m4 --> m5(Assignment: pop out eligible record to hospitals)
m5 --> m6(Test time and generate weekly or monthly report)
end
A person can register for medical treatment at a local registry. For the registration the following information is required:
– the identification number of the person,
– the name and contact details (address, phone, WeChat, email) of the person,
– the profession of the person,
– the date of birth of the person,
– the medical risk status of the person.
Each registration record will receive a timestamp, i.e. the date and the time of the registration will be stored. The professions are classified into eight profession categories I to VIII. There are seven age groups: children (≤ 12 years), adolescents (≤ 18 years), young adults (≤ 35 years), adults (≤ 50 years), seniors (≤ 65 years), elderly people (≤ 75 years), and old people (> 75 years). There are four different risk status: no risk (0), low risk (1), medium risk(2), and high risk (3).
Registration records are stored permanently. In addition, records with relevant information such as identification, profession category, age category, risk status, registration date and time are kept in a queue, which twice daily is forwarded to the centralised treatment queue. Data from different local registries is added to the centralised queue in random order, but the order from the local queues is preserved.
The assignment of an appointment for receiving treatment is organised according to priority. The most important criterion is the profession category followed by a ranking of age groups, and further followed by data and time of the registration. Only people with no or low risk are considered. For people with medium risk a one month extension is added; people with high risk are only considered when there are no others waiting in the queue.
A person may withdraw from the treatment at any time. Those who have withdrawn and then registered again are considered with additional two weeks waiting time, unless they are in the medium or high risk group.
Furthermore, the profession category and the risk status of a queueing person may change. If this affects increases the priority in the queue, the relevant attributes are updated. A person may also present a priority letter with a deadline for the treatment. At the latest a person is assigned an appointment before the deadline regardless of the other selection criteria.
When a person has highest priority in the priority queue, an appointment location, date and time (usually the next day) is assigned and registered. With this the person leaves the queue. There are several locations for treatment processing each with a daily capacity and associated time slots for the treatment. Usually, the closest location is selected for a person.
The right to withdraw is reserved. When the treatment has been processed at the designated location at the reserved day and time, this is also registered
The system shall produce weekly reports comprising
– the people who have been treated including their profession category, age category, risk status and the waiting time from registration to treatment,
– the registered people with a set appointment including their profession category, age category, risk status and their waiting time until now,
– the queueing people without a set appointment including their profession category, age category, risk status and their waiting time until now.
It must be possible to order these reporting lists by name, profession category or age group. In addition the system shall produce a monthly statistics report showing how many people have registered, how many of them are waiting, how many are waiting in total, how many treatment appointments have been made, the average waiting time, and the number of people who withdrew their registration.
We set 5 registries and 3 hospitals.
The prepared input files are 5 registry_n.csv files, each file contains 500 people, each file represents the person that are registered in a registry. Each half day there will be 5 people per registry, 25 people in total, being plugged from the file to the queue, standing for that they were registered.
And each hospital, can deal with 8 people per day. Each day, although the queues put people into Fibonacci heap for twice, the hospital only makes appointments for the next day by once. After they are “treated”, they will be put into an Alist archive.
Each person will have the following arttributes: id, registration, name, address, phone, Wechat, profession, birth, register_time, risk status, hospital, regist_halfday, treat_halfday, withdraw, withdraw_halfday, reinsert_halfday, risk2halfday, ddlletter, treatment, Euclidean_address, health_care_card;
And these properties are stored into 4 relations which are in struct form. We established a B+ tree for each relation, thus there are 4 in total, and these B+ trees use id as the primary key. Also, we establish a B tree and a hash table to search for data based on secondary keys, health card number and risk status resp. When you enter the secondary key information, you can get the id and search for the corresponding information of those people with the secondary key in the B + tree.
Download all the files and run makefile, all the information to display will be shown on the console. There are two checkpoints, follow the user interface and test our system. Have fun!