PAGE2S社區(qū)醫(yī)院預(yù)約掛號(hào)管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)摘要目前，傳統(tǒng)的醫(yī)院預(yù)約掛號(hào)正在逐漸被公平高效的網(wǎng)上預(yù)約掛號(hào)所代替，我國目前醫(yī)院排隊(duì)掛號(hào)依舊是主流，導(dǎo)致醫(yī)院效率低、醫(yī)務(wù)人員工作強(qiáng)度大，患者就醫(yī)體驗(yàn)差等糟糕情況。為了提高醫(yī)院效率同時(shí)改善老百姓的就醫(yī)體驗(yàn)，黨中央不斷下發(fā)官方文件，要求加快實(shí)現(xiàn)綜合掛號(hào)平臺(tái)建設(shè)，逐步實(shí)現(xiàn)平臺(tái)與國家數(shù)據(jù)共享交換平臺(tái)的對(duì)接，爭(zhēng)取早日實(shí)現(xiàn)現(xiàn)代化醫(yī)療目標(biāo)。“S社區(qū)醫(yī)院預(yù)約掛號(hào)管理系統(tǒng)”正是在此背景下誕生，本文圍繞以互聯(lián)網(wǎng)技術(shù)打造一項(xiàng)惠民便民的預(yù)約掛號(hào)綜合平臺(tái)。系統(tǒng)包括Web用戶端、Web管理員端、后臺(tái)、系統(tǒng)服務(wù)組件四部分，Web用戶端和Web管理員端采用Vue、Axios、Node和ElementUI等技術(shù)開發(fā)，后臺(tái)采用SpringBoot、SpringCloud和MP框架，系統(tǒng)服務(wù)組件采用Nignx、Nacos、Docker。關(guān)鍵詞：互聯(lián)網(wǎng)；健康醫(yī)療；平臺(tái)建設(shè)目錄TOC\o"1-2"\h\u30407摘要 II130001緒論101551.1目的和意義 (1)306041.2背景及國內(nèi)外現(xiàn)狀 (1)290321.3研究的內(nèi)容 (3)39991.4論文結(jié)構(gòu) (4)259731.5本章小結(jié) (4)310842需求分析185092.1可行性分析 (5)66052.2功能需求分析 (7)39922.3業(yè)務(wù)流程分析 (10)167082.4非功能性需求分析 (12)156892.5本章小結(jié) (13)306053概要設(shè)計(jì)229053.1系統(tǒng)總體設(shè)計(jì) (14)282883.2系統(tǒng)功能模塊劃分 (15)307723.3數(shù)據(jù)庫設(shè)計(jì) (17)218023.4本章小結(jié) (31)48054詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)216134.1開發(fā)及運(yùn)行環(huán)境描述 (32)307804.2實(shí)名認(rèn)證模塊 (32)25374.3掛號(hào)訂單模塊 (33)305314.4就診人管理模塊 (34)151104.5注冊(cè)登錄模塊 (35)131814.6用戶管理模塊 (36)23754.7數(shù)據(jù)管理模塊 (37)273994.8醫(yī)院管理模塊 (38)313244.9訂單管理模塊 (39)217144.10統(tǒng)計(jì)管理模塊 (40)311074.11醫(yī)院設(shè)置模塊 (41)181534.12科室排班管理模塊 (42)259154.13本章小結(jié) (43)30505系統(tǒng)測(cè)試49565.1測(cè)試目的 (44)187415.2功能性測(cè)試 (44)181865.3非功能性測(cè)試 (50)91185.4本章小結(jié) (50)120606總結(jié)與展望324206.1總結(jié) (51)309636.2展望 (51)8917參考文獻(xiàn) (54)PAGE21緒論本章是決定項(xiàng)目開發(fā)意義的重要一環(huán)，研究項(xiàng)目的來源與背景，探討項(xiàng)目的意義，描繪出項(xiàng)目研究?jī)?nèi)容與方向的大致輪廓，制定相應(yīng)的計(jì)劃去完成項(xiàng)目。1.1目的和意義方便群眾就醫(yī),減少就醫(yī)排隊(duì)時(shí)間，優(yōu)化醫(yī)院的就醫(yī)流程，使醫(yī)院資源調(diào)控更加合理，讓醫(yī)院服務(wù)質(zhì)量更好REF_Ref91615032\r\h[1]。同時(shí)讓病人可以根據(jù)自己的時(shí)間去選擇就醫(yī)，使就醫(yī)時(shí)間時(shí)間更加靈活。醫(yī)院使用網(wǎng)上預(yù)約掛號(hào)系統(tǒng)，可以幫助患者很方便的掛到號(hào)，提升醫(yī)院服務(wù)能力，使醫(yī)院的資源調(diào)控更加合理，降低醫(yī)療安全風(fēng)險(xiǎn)REF_Ref32636\r\h[2REF_Ref642\r\h,3]。為了規(guī)范和推動(dòng)預(yù)約掛號(hào)服務(wù)，黨中央下達(dá)了相關(guān)文件，指示相關(guān)醫(yī)院要實(shí)行預(yù)約服務(wù)，同時(shí)，也要培養(yǎng)醫(yī)務(wù)人員相關(guān)服務(wù)技能，優(yōu)化醫(yī)院管理制度，努力打造更加完善的模式REF_Ref22443\r\h[5REF_Ref22466\r\h,6]。1.2背景及國內(nèi)外現(xiàn)狀當(dāng)前，疫情逐漸常態(tài)化，在面對(duì)醫(yī)院患者日益增長(zhǎng)的同時(shí)醫(yī)院資源分配不均和醫(yī)療資源比較緊張等諸多問題也越發(fā)嚴(yán)重，選擇一個(gè)有效的方法來解決此問題變得極為迫切。其中大型醫(yī)院掛號(hào)難是一個(gè)突出問題REF_Ref25254\r\h[7REF_Ref14296\r\h,8]。此外，在全面小康的背景下，老百姓對(duì)身體健康的重視程度越來越高，也對(duì)醫(yī)院的醫(yī)療服務(wù)質(zhì)量和就診體驗(yàn)有了更高的要求。目前，在一些經(jīng)濟(jì)落后地區(qū)的甲級(jí)醫(yī)院和大量小醫(yī)院在處理業(yè)務(wù)時(shí)依舊采用傳統(tǒng)方式，并沒有通過互聯(lián)網(wǎng)技術(shù)來提高效率，導(dǎo)致醫(yī)務(wù)人員和醫(yī)院效率較低，同時(shí)患者經(jīng)常面臨花費(fèi)大量時(shí)間浪費(fèi)在排隊(duì)掛號(hào)的等待上，而真正有效的就診時(shí)間就幾分鐘[5]。據(jù)2016-2020年網(wǎng)上醫(yī)院預(yù)約調(diào)查報(bào)告資料顯示，在一千多人的受訪者中，有超過88%的人覺得去醫(yī)院看病很難，其中最難的就是預(yù)約掛號(hào)，有超過31.7%的被訪者對(duì)醫(yī)院效率低和掛號(hào)排隊(duì)時(shí)間長(zhǎng)最不滿意REF_Ref17767\r\h[9]。在國內(nèi)，人們對(duì)身體健康的重視程度越來越高，面對(duì)越來越多的醫(yī)療需求，以目前的公共醫(yī)療資源很難應(yīng)對(duì)REF_Ref5005\r\h[9]。為了解決這些民生問題，中央在2015下發(fā)的官方文件明確指出，各級(jí)醫(yī)院要服從中央指示，要自我優(yōu)化，以互聯(lián)網(wǎng)為基礎(chǔ)結(jié)合科技力量對(duì)醫(yī)療服務(wù)質(zhì)量進(jìn)行從下向上的變更，穩(wěn)步推進(jìn)預(yù)約掛號(hào)服務(wù)和產(chǎn)業(yè)的全面實(shí)現(xiàn)。在國外，特別是歐美發(fā)達(dá)國家，由于他們發(fā)展的比較早，使他們擁有了比較先進(jìn)的醫(yī)療系統(tǒng)，通?；颊邥?huì)有意識(shí)地提前和醫(yī)生溝通，約定就醫(yī)時(shí)間，很少會(huì)存在掛號(hào)難、白跑一趟的問題。通常情況下，他們的大醫(yī)院不會(huì)接受普通患者預(yù)約，只會(huì)對(duì)重癥病人進(jìn)行治療，所以他們醫(yī)院的效率才會(huì)很高。1.3研究的內(nèi)容論文首先以網(wǎng)上預(yù)約掛號(hào)平臺(tái)的市場(chǎng)需求研究背景，確定了網(wǎng)上預(yù)約掛號(hào)管理系統(tǒng)致力于的主要目標(biāo)和對(duì)現(xiàn)實(shí)社會(huì)的兩個(gè)重要意義，一是，幫助醫(yī)院高效率的管理醫(yī)藥的預(yù)約掛號(hào)數(shù)據(jù)，并減輕醫(yī)務(wù)人員的工作壓力；二是，幫助患者在節(jié)省時(shí)間和金錢的同時(shí)提高就醫(yī)體驗(yàn)。其次結(jié)合市場(chǎng)環(huán)境對(duì)網(wǎng)上預(yù)約掛號(hào)平臺(tái)的現(xiàn)狀進(jìn)行了網(wǎng)上資料調(diào)查。在系統(tǒng)開發(fā)的過程當(dāng)中，我主要對(duì)系統(tǒng)需求分析、概要計(jì)、詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)以及系統(tǒng)測(cè)試等各個(gè)環(huán)節(jié)做仔細(xì)的設(shè)計(jì)實(shí)現(xiàn)。除此之外，我對(duì)項(xiàng)目的技術(shù)選型進(jìn)行了挑選并對(duì)項(xiàng)目涉及到的業(yè)務(wù)、流程、角色功能等都做了仔細(xì)地分析。論文主要內(nèi)容結(jié)構(gòu)包括：首先，基于系統(tǒng)業(yè)務(wù)以及結(jié)構(gòu)分析，分析系統(tǒng)中涉及到的角色以及不同角色所擁有的功能；其次，根據(jù)系統(tǒng)的需求梳理出系統(tǒng)的現(xiàn)實(shí)場(chǎng)景，結(jié)合微服務(wù)的思想設(shè)計(jì)了系統(tǒng)架構(gòu)和功能模塊；然后，根據(jù)設(shè)計(jì)模塊使用流程圖和時(shí)序圖；最后，對(duì)所有模塊進(jìn)行功能性測(cè)試和非功能性模塊進(jìn)行現(xiàn)實(shí)場(chǎng)景分析測(cè)試，并給出測(cè)試用例。1.4論文結(jié)構(gòu)論文的內(nèi)容結(jié)構(gòu)共有六章，論文主要分析了S社區(qū)醫(yī)院預(yù)約掛號(hào)管理系統(tǒng)在不同階段各個(gè)章節(jié)的設(shè)計(jì)、分析與實(shí)現(xiàn)，具體結(jié)構(gòu)如下：第一章：通過數(shù)據(jù)說明課題對(duì)國家和個(gè)人的意義，明確課題內(nèi)容和結(jié)構(gòu)。第二章：對(duì)課題所涉及的各個(gè)需求進(jìn)行展開分析。第三章：分析整個(gè)系統(tǒng)的各個(gè)模塊以及數(shù)據(jù)庫的整體設(shè)計(jì)第四章：簡(jiǎn)要概述系統(tǒng)環(huán)境和開發(fā)技術(shù)，并分析各個(gè)模塊的具體實(shí)現(xiàn)。第五章：對(duì)系統(tǒng)的各個(gè)功能模塊和整體的穩(wěn)定性、可靠性進(jìn)行系統(tǒng)性的測(cè)試。第六章：回顧整個(gè)項(xiàng)目的開發(fā)歷程，總結(jié)開發(fā)過程的問題和收獲。1.5本章小結(jié)為了解決看病難、掛號(hào)難的就醫(yī)難題，本章結(jié)合國內(nèi)外的掛號(hào)就醫(yī)情況對(duì)比，采用系統(tǒng)性分析方法，分析了目前我國現(xiàn)階段看病就醫(yī)存在的問題并通過對(duì)比國外先進(jìn)高效的做法，結(jié)合自己的觀點(diǎn)，提出了切實(shí)可行的解決辦法。

2需求分析需求分析是整個(gè)項(xiàng)目能否進(jìn)行下一步的基礎(chǔ)，一個(gè)合格的需求分析應(yīng)當(dāng)包含以下三個(gè)部分：可行性分析、功能需求分析和業(yè)務(wù)流程分析，每個(gè)分析都要圍繞需求的主題展開，并切實(shí)地給出分析結(jié)論。2.1可行性分析在項(xiàng)目的研究?jī)?nèi)容和方向確定之后，首先要進(jìn)行的就是可行性分析，在分析的過程中，我們要結(jié)合實(shí)際情況和真實(shí)數(shù)據(jù)分析而不能憑自己的主觀猜想分析，在分析了所有的可行性之后，我們應(yīng)當(dāng)總結(jié)判斷每一項(xiàng)的可行性是否真正可行。除此之外，我們還應(yīng)當(dāng)分析此過程中的問題以及給出可行的解決方案，再從可行的方案中挑選出一個(gè)最符合同時(shí)也是最可行的方案。通常，從經(jīng)濟(jì)、技術(shù)和市場(chǎng)三個(gè)角度對(duì)系統(tǒng)開發(fā)可行性進(jìn)行研究分析。下面我將從這三個(gè)角度對(duì)可行性展開分析。2.1.1經(jīng)濟(jì)可行性開發(fā)該系統(tǒng)所使用的開發(fā)軟件，都是可以到相關(guān)網(wǎng)站免費(fèi)下載到的如Xshell、Navicat、IDEA、WebStorm、Mysql及JDK等，除了在搭建微服務(wù)的運(yùn)行和維護(hù)環(huán)境上需要一臺(tái)服務(wù)器以及短信服務(wù)外沒有其他經(jīng)濟(jì)方面的支出，因此不存在經(jīng)濟(jì)負(fù)擔(dān)過重的問題，所以從經(jīng)濟(jì)方面考慮開發(fā)該系統(tǒng)是可行的。2.1.2技術(shù)可行性通過在大學(xué)期間專業(yè)系統(tǒng)學(xué)習(xí)和幾個(gè)項(xiàng)目的實(shí)踐操作，在技術(shù)層面上已經(jīng)有足夠多的經(jīng)驗(yàn)。從現(xiàn)有的計(jì)算機(jī)軟件、硬件資源方面看，也是可以滿足系統(tǒng)在數(shù)據(jù)處理、運(yùn)算速度等方面的開發(fā)需求。開發(fā)該系統(tǒng)所采用的開發(fā)技術(shù)有Java、Vue、ElementUI、Mysql、SpringBoot、SpringCloud等。所以從技術(shù)方面考慮技術(shù)是可行的。2.1.3市場(chǎng)可行性分析市場(chǎng)可行性我將從兩個(gè)方面進(jìn)行調(diào)研和數(shù)據(jù)分析，其一是，中國目前互聯(lián)網(wǎng)網(wǎng)民的數(shù)量，這是網(wǎng)上預(yù)約掛號(hào)系統(tǒng)是否可行的必要條件；其二是，中國平均每個(gè)月的患者就診人數(shù)，這關(guān)系到網(wǎng)上預(yù)約掛號(hào)的需求量和發(fā)展前景。下面我將根據(jù)以上兩點(diǎn)通過兩組數(shù)據(jù)來分析網(wǎng)上預(yù)約掛號(hào)的市場(chǎng)可行性。其一，根據(jù)網(wǎng)信辦的互聯(lián)網(wǎng)發(fā)展報(bào)告顯示，目前中國網(wǎng)民數(shù)量超十億，達(dá)10.11億人REF_Ref5820\r\h[10]。其二，根據(jù)國家衛(wèi)健委統(tǒng)計(jì)信息中心在官網(wǎng)發(fā)布了的《2021年4月全國醫(yī)療服務(wù)情況》分析報(bào)告顯示，2021年4月，全國共計(jì)5.3億人次就診。從以上兩組數(shù)據(jù)不難看出，中國擁有10億級(jí)別的互聯(lián)網(wǎng)用戶群體且每月就診人數(shù)平均在4至5億人次左右，面對(duì)如此龐大的就診人數(shù)，如何有效的解決醫(yī)院的壓力以及有條不紊的安排診斷變得至關(guān)重要。在此背景下，網(wǎng)上預(yù)約掛號(hào)無疑有著巨大的優(yōu)勢(shì)以及發(fā)展?jié)摿Α；谥袊鴵碛?2多億智能移動(dòng)手機(jī)用戶和每月平均幾億的就醫(yī)人數(shù)，我認(rèn)為市場(chǎng)是可行的。2.2功能需求分析平臺(tái)用戶：（1）醫(yī)院信息展示：掛號(hào)平臺(tái)需要對(duì)醫(yī)院的詳細(xì)信息進(jìn)行介紹并對(duì)科室、排班進(jìn)行信息展示，其中科室信息展示需要展示科室的具體信息讓患者能夠清晰的知道不同科室的詳細(xì)情況；排班介紹需要向患者展示醫(yī)院的近期對(duì)應(yīng)科室的排班安排、坐診的醫(yī)師以及掛號(hào)容量等信息。通過醫(yī)院信息展示減低系統(tǒng)使用的復(fù)雜度同時(shí)減少用戶不必要的操作錯(cuò)誤。（2）用戶就診人管理：對(duì)于已經(jīng)登陸的用戶，用戶可以添加就診人，此外，可以對(duì)需要修改的就診人進(jìn)行信息修改或者刪除就診人。（3）在線掛號(hào)：用戶在掛號(hào)平臺(tái)選擇需要掛號(hào)的醫(yī)院和科室，在掛號(hào)頁面，用戶可以清晰的看到醫(yī)院的排班信息，并對(duì)需要掛號(hào)的時(shí)間進(jìn)行選擇，掛號(hào)成功之后，用戶可收到掛號(hào)成功的短信通知。（4）查詢與取消預(yù)約：用戶在掛號(hào)平臺(tái)成功掛號(hào)之后，用戶可以查看自的掛號(hào)訂單的詳細(xì)信息。查詢到掛號(hào)訂單之后，用戶可以根據(jù)需要選擇是否進(jìn)行取消掛號(hào)操作，取消之后用戶將收到取消掛號(hào)的短信通知。用戶用例圖如圖2-1所示。圖2-1用戶用例圖平臺(tái)管理員：（1）用戶管理：這個(gè)模塊分為兩個(gè)部分：一是用戶的賬號(hào)管理，二是用戶的實(shí)名認(rèn)證管理，由于系統(tǒng)的只提供了手機(jī)短信登錄和微信授權(quán)登錄兩種登陸模式?jīng)]有提供注冊(cè)功能，當(dāng)用戶使用手機(jī)短信驗(yàn)證登錄時(shí)，系統(tǒng)會(huì)創(chuàng)建一個(gè)用戶賬號(hào)并將該手機(jī)號(hào)綁定用戶賬號(hào)并以此作為后續(xù)掛號(hào)通知的手段，如果用戶選擇微信授權(quán)登錄，系統(tǒng)則會(huì)在創(chuàng)建一個(gè)用戶賬號(hào)的同時(shí)獲取掃碼人的微信信息并判斷其中是否存在用戶手機(jī)信息，如果沒有則跳轉(zhuǎn)到手機(jī)短信綁定界面，通過以上兩種判斷方式確保用戶賬號(hào)可以和手機(jī)號(hào)綁定。在完成以上操作后，用戶還需要進(jìn)行實(shí)名認(rèn)證，方式有兩種，分別是身份證和戶口本認(rèn)證，認(rèn)證成功后用戶才能真正進(jìn)行預(yù)約掛號(hào)操作。（2）數(shù)據(jù)管理：這個(gè)模塊只有一個(gè)數(shù)據(jù)字典功能部分，主要是對(duì)全國的各個(gè)省、市、縣等地級(jí)信息、醫(yī)院等級(jí)、證件類型、學(xué)歷、民族等系統(tǒng)需要使用的一些全局公有屬性數(shù)據(jù)進(jìn)行管理，主要的操作功能有：查看數(shù)據(jù)、導(dǎo)入數(shù)據(jù)和導(dǎo)出數(shù)據(jù)。（3）醫(yī)院管理：這個(gè)模塊功能主要是對(duì)醫(yī)院設(shè)置和醫(yī)院列表進(jìn)行管理，其中醫(yī)院設(shè)置可以查看醫(yī)院的部分信息、對(duì)醫(yī)院的可使用狀態(tài)進(jìn)行鎖定和取消鎖定操作，通過醫(yī)院名稱和醫(yī)院編號(hào)進(jìn)行條件查詢，通過醫(yī)院的id刪除或者通過醫(yī)院的id數(shù)組進(jìn)行批量刪除。（4）訂單管理：訂單管理模塊可以對(duì)所有的用戶訂單進(jìn)行統(tǒng)一管理，其中可以根據(jù)用戶的id查詢這個(gè)用戶的所有訂單數(shù)據(jù)，也可通過點(diǎn)擊訂單查看訂單的詳細(xì)信息。（5）統(tǒng)計(jì)管理：對(duì)系統(tǒng)的訂單和醫(yī)院等做數(shù)據(jù)上的統(tǒng)計(jì)分析，通過echarts圖表表現(xiàn)。管理員用例圖如圖2-2所示。圖2-2管理員用例圖醫(yī)院對(duì)接人：（1）醫(yī)院設(shè)置：需要醫(yī)院對(duì)接人員在醫(yī)院設(shè)置頁面填寫醫(yī)院編號(hào)code、平臺(tái)簽發(fā)的簽名密鑰key和統(tǒng)一預(yù)約掛號(hào)平臺(tái)基礎(chǔ)路徑這三個(gè)平臺(tái)對(duì)接的必要信息，只有填寫了以上三個(gè)信息，醫(yī)院才能真正向平臺(tái)上傳醫(yī)院的相關(guān)數(shù)據(jù)。；（2）醫(yī)院管理：在醫(yī)院對(duì)接人員登錄醫(yī)院醫(yī)院管理平臺(tái)并正確填寫醫(yī)院設(shè)置信息之后，對(duì)接人員需要上傳醫(yī)院的基本價(jià)紹信息，其中包括醫(yī)院基本介紹和醫(yī)院預(yù)約掛號(hào)好規(guī)則，只有上傳了這些信息，用戶才能對(duì)醫(yī)院有清晰的了解，才能正確的進(jìn)行掛號(hào)。此外對(duì)于醫(yī)院以后需要變更醫(yī)院基本信息要擁有數(shù)據(jù)變更的操作功能。（3）科室列表：在醫(yī)院對(duì)接人員登錄醫(yī)院管理平臺(tái)之后，對(duì)接人員需要按時(shí)上傳醫(yī)院的全部科室的相關(guān)信息，保證掛號(hào)平臺(tái)可以進(jìn)行醫(yī)院科室展示，同時(shí)科室列表中必須擁有科室操作的功能，保證醫(yī)院可以隨時(shí)對(duì)科室進(jìn)行操作。（4）排班列表：在醫(yī)院對(duì)接人員登錄醫(yī)院管理平臺(tái)之后，對(duì)接人員需要按時(shí)上傳醫(yī)院的全部排班的相關(guān)信息，確保用戶能夠即使根據(jù)醫(yī)院排版進(jìn)行醫(yī)院的預(yù)約掛號(hào)，同時(shí)排班列表中必須擁有排班操作的功能，保證醫(yī)院可以隨時(shí)對(duì)排班進(jìn)行相應(yīng)的操作。醫(yī)院對(duì)接人員用例圖如圖2-3所示。圖2-3醫(yī)院人員用例圖2.3業(yè)務(wù)流程分析本項(xiàng)目的主要目標(biāo)是針對(duì)那些有預(yù)約掛號(hào)需求的用戶，整個(gè)系統(tǒng)的業(yè)務(wù)流程可分為，登錄、實(shí)名認(rèn)證、添加就診人、選擇醫(yī)院掛號(hào)、支付、短信通知。預(yù)約掛號(hào)的業(yè)務(wù)流程如下。用戶選擇手機(jī)短信驗(yàn)證登錄或者微信授權(quán)登錄，如果選擇手機(jī)短信登錄系統(tǒng)會(huì)創(chuàng)建一個(gè)用戶賬號(hào)并將該手機(jī)號(hào)綁定用戶賬號(hào)并以此作為后續(xù)掛號(hào)通知的手段，如果用戶選擇微信授權(quán)登錄，系統(tǒng)則會(huì)在創(chuàng)建一個(gè)用戶賬號(hào)的同時(shí)獲取掃碼人的微信信息并判斷其中是否存在用戶手機(jī)信息，如果沒有則跳轉(zhuǎn)到手機(jī)短信綁定界面，在完成以上操作后，用戶還需要進(jìn)行實(shí)名認(rèn)證，方式有兩種，分別是身份證和戶口本認(rèn)證，用戶提交認(rèn)證后，系統(tǒng)管理員會(huì)對(duì)認(rèn)證進(jìn)行審核，當(dāng)審核通過之后，用戶選擇需要的醫(yī)院、科室、時(shí)間進(jìn)行掛號(hào)，掛號(hào)成功后用戶將收到短信提示。預(yù)約掛號(hào)業(yè)務(wù)流程圖如圖2-1所示。圖2-1預(yù)約掛號(hào)業(yè)務(wù)流程圖醫(yī)院平臺(tái)對(duì)接業(yè)務(wù)流程圖如圖2-2所示。圖2-2醫(yī)院平臺(tái)對(duì)接業(yè)務(wù)流程圖查詢與取消預(yù)約業(yè)務(wù)流程圖如圖2-3所示圖2-3用戶取消預(yù)約業(yè)務(wù)流程圖2.4非功能性需求分析對(duì)界面多端適配需求、易用好擴(kuò)展需求、穩(wěn)定安全需求等方面進(jìn)行考慮，以下是具體的分析：（1）界面多端適配性。用戶在使用掛號(hào)平臺(tái)的過程當(dāng)中可能使用不同的操作設(shè)備，不同的瀏覽器。面臨這種情況系統(tǒng)要具備多環(huán)境適應(yīng)性，讓其在不同的終端上任然擁有理想的界面展示。（2）穩(wěn)定安全性：生產(chǎn)環(huán)境中，系統(tǒng)通常都是24小時(shí)不間斷運(yùn)行并有可能面臨高并發(fā)狀況，同時(shí)也可能隨時(shí)遭遇不法分子的網(wǎng)絡(luò)攻擊，所以在面對(duì)這些問題時(shí)，要求系統(tǒng)必須具備在高并發(fā)的情況下保持高可用，在面對(duì)大量用戶同時(shí)訪問時(shí)能夠保持穩(wěn)定的運(yùn)行，同時(shí)能夠24小時(shí)不間斷的提供服務(wù)、具備抵御SQL注入、DOS攻擊、XSS攻擊等網(wǎng)絡(luò)攻擊手段。（3）易用擴(kuò)展性：包括界面的美觀性，要求系統(tǒng)要簡(jiǎn)潔大方、容易理解，同時(shí)平臺(tái)的使用要符合我們?nèi)粘Ａ?xí)慣的操作方式；和在面對(duì)未來變更業(yè)務(wù)或者添加新業(yè)務(wù)時(shí)可以輕松的在原有的基礎(chǔ)上進(jìn)行擴(kuò)展操作和修改同時(shí)不影響其他無關(guān)業(yè)務(wù)。2.5本章小結(jié)本章對(duì)系統(tǒng)作了全面的需求分析，首先從三個(gè)不同角度分別分析可行性。在可行性成立的基礎(chǔ)上再從系統(tǒng)深層次分析各個(gè)需求，保證自己對(duì)系統(tǒng)的整體有足夠詳細(xì)的認(rèn)識(shí)。

3概要設(shè)計(jì)概要設(shè)計(jì)是把用戶目標(biāo)與需求轉(zhuǎn)換成具體界面解決方案的重要階段，其任務(wù)是建立目標(biāo)系統(tǒng)的總體結(jié)構(gòu)和模塊之間的關(guān)系，定義并控制各功能模塊的接口，并逐步實(shí)現(xiàn)設(shè)計(jì)目標(biāo)。3.1系統(tǒng)總體設(shè)計(jì)根據(jù)項(xiàng)目的開發(fā)需求和設(shè)計(jì)標(biāo)準(zhǔn)，系統(tǒng)采用分布式微服務(wù)架構(gòu)，使用SpringBoot和SpringCloud框架來構(gòu)建整個(gè)系統(tǒng)的骨架，采用Nginx負(fù)載均衡器和SpringCloudGateway網(wǎng)關(guān)來實(shí)現(xiàn)系統(tǒng)入口的負(fù)載均衡，同時(shí)為了解決系統(tǒng)所有模塊的服務(wù)治理和每個(gè)模塊的在負(fù)載均衡前提下并發(fā)量過的問題，系統(tǒng)引入SpringCloudAlibaba相關(guān)組件Nacos和Sentinel，通過Nacos注冊(cè)和配置中心實(shí)現(xiàn)服務(wù)注冊(cè)與發(fā)現(xiàn)并通過可視化的界面隨時(shí)查看系統(tǒng)所有服務(wù)的運(yùn)行狀態(tài)并可以控制服務(wù)的上線和下線，而Sentinel則實(shí)現(xiàn)了服務(wù)的熔斷降級(jí)和限流；除此之外，系統(tǒng)采用redis作為系統(tǒng)的緩存，以此來減輕Mysql數(shù)據(jù)庫的訪問壓力，同時(shí)使用Mongodb作為系統(tǒng)數(shù)據(jù)庫的擴(kuò)展數(shù)據(jù)庫，以Mongodb的高性能來解決前端頁面經(jīng)常查詢的數(shù)據(jù)的訪問壓力。使用微服務(wù)解決了SSM單體應(yīng)用框架的高內(nèi)聚性，將系統(tǒng)進(jìn)行多個(gè)不同模塊的劃分，每個(gè)模塊相互獨(dú)立，每個(gè)模塊之間通過RPC遠(yuǎn)程調(diào)用相互協(xié)作完成整個(gè)系統(tǒng)的各個(gè)功能，這樣讓系統(tǒng)的各個(gè)模塊耦合度大大降低，系統(tǒng)整體架構(gòu)如圖3-1所示。圖3-1系統(tǒng)總體架構(gòu)圖3.2系統(tǒng)功能模塊劃分通過對(duì)S社區(qū)醫(yī)院預(yù)約掛號(hào)管理系統(tǒng)的所有業(yè)務(wù)和涉及的人員進(jìn)行分析，我將整個(gè)系統(tǒng)分為用戶前端掛號(hào)平臺(tái)、系統(tǒng)后臺(tái)管理平臺(tái)、醫(yī)院后臺(tái)管理平臺(tái)這三大主模塊，其中每個(gè)主模塊下有多個(gè)不同子功能模塊。具體的系統(tǒng)總體功能結(jié)構(gòu)如圖3-2所示。用戶前端掛號(hào)平臺(tái)包含四個(gè)子功能模塊分別是：（1）注冊(cè)登錄模塊：新用戶可以通過手機(jī)號(hào)或者微信掃碼注冊(cè)的同時(shí)登錄掛號(hào)平臺(tái)。（2）實(shí)名認(rèn)證模塊：登錄成功之后，用戶必須選擇身份證或者戶口本進(jìn)行實(shí)名認(rèn)證才能掛號(hào)。（3）掛號(hào)訂單模塊：用戶掛號(hào)成功之后可以在掛號(hào)訂單模塊里查看到自己的所有掛號(hào)訂單。（4）就診人管理：用戶可以自行添加就診人并為添加的就診人掛號(hào)。系統(tǒng)后臺(tái)管理平臺(tái)包含五個(gè)功能模塊分別是：（1）用戶管理模塊：平臺(tái)管理員可以對(duì)用戶管理模塊下的用戶列表和認(rèn)真審核列表進(jìn)行相應(yīng)的數(shù)據(jù)操作，包括查看用戶信息、同意認(rèn)證、鎖定用戶等操作。（2）數(shù)據(jù)管理模塊：平臺(tái)管理員可以對(duì)數(shù)據(jù)管理模塊下的字典列表進(jìn)行導(dǎo)入數(shù)據(jù)、導(dǎo)出數(shù)據(jù)、查看數(shù)據(jù)等相關(guān)操作。（3）醫(yī)院管理模塊：平臺(tái)管理員可以對(duì)醫(yī)院管理模塊下的醫(yī)院列表、醫(yī)院設(shè)置進(jìn)行進(jìn)行醫(yī)院信息查看、醫(yī)院鎖定、排班查看、醫(yī)院設(shè)置刪除等等相關(guān)操作。（4）訂單管理模塊：平臺(tái)管理員可以對(duì)訂單管理模塊下的訂單列表進(jìn)行訂單查看、訂單搜索等相關(guān)數(shù)據(jù)操作。（5）統(tǒng)計(jì)管理模塊：平臺(tái)管理員可以對(duì)統(tǒng)計(jì)管理模塊下的預(yù)約訂單統(tǒng)計(jì)圖圖表進(jìn)行查看操作。醫(yī)院后臺(tái)管理平臺(tái)包含四個(gè)功能模塊分別是：（1）醫(yī)院設(shè)置模塊：醫(yī)院對(duì)接人員可以在醫(yī)院設(shè)置模塊下對(duì)醫(yī)院編號(hào)code、醫(yī)院簽名key、接入地址進(jìn)行數(shù)據(jù)操作。（2）醫(yī)院管理模塊：醫(yī)院對(duì)接人員可以在醫(yī)院管理模塊下醫(yī)院基本信息、醫(yī)院排班規(guī)則進(jìn)行更改、查看、上傳等相關(guān)操作。（3）科室列表模塊：醫(yī)院對(duì)接人員可以在科室列表模塊下進(jìn)行科室數(shù)據(jù)上傳、科室信息查看等相關(guān)操作。（4）排班列表模塊：醫(yī)院對(duì)接人員可以在排班列表模塊下進(jìn)行排班數(shù)據(jù)上傳、排班信息查看等相關(guān)操作。圖3-2系統(tǒng)總體功能模塊圖3.3數(shù)據(jù)庫設(shè)計(jì)在我們計(jì)數(shù)據(jù)庫的過程中還應(yīng)當(dāng)遵循規(guī)范的數(shù)據(jù)庫設(shè)計(jì)標(biāo)準(zhǔn)，其中第三范式是目前使用最多同時(shí)也是最優(yōu)的選擇，它可以很好的解決數(shù)據(jù)重復(fù)問題并減輕了數(shù)據(jù)庫的存儲(chǔ)壓力[16]。所以，本項(xiàng)目數(shù)據(jù)庫在設(shè)計(jì)時(shí)遵循了次設(shè)計(jì)規(guī)范，使得數(shù)據(jù)庫可以在減低冗余的同時(shí)實(shí)現(xiàn)數(shù)據(jù)庫整體性能的提升。在數(shù)據(jù)庫表屬性字段類型的選擇方面，我們要結(jié)合字段的實(shí)際使用出發(fā)，盡可能的使用節(jié)省資源的數(shù)據(jù)類型，通過優(yōu)先選擇內(nèi)存占用小的數(shù)據(jù)類型，從而達(dá)到節(jié)省服務(wù)資源。此外對(duì)于經(jīng)常進(jìn)行查詢操作的字段，我們應(yīng)該優(yōu)先考慮為其建立索引，通過索引提高數(shù)據(jù)庫的查詢性能，讓數(shù)據(jù)庫發(fā)揮最大效率。3.3.1概念設(shè)計(jì)數(shù)據(jù)庫概念設(shè)計(jì)將決定數(shù)據(jù)庫的主導(dǎo)，通過建立概念和邏輯模型對(duì)數(shù)據(jù)庫有一個(gè)總體的認(rèn)識(shí)，根據(jù)數(shù)據(jù)庫的設(shè)計(jì)策略將采用自底向上的方法先定義各局部應(yīng)用的概念結(jié)構(gòu)E-R圖，然后形成全局結(jié)構(gòu)E-R模型。系統(tǒng)用戶E-R圖如圖3-3所示。圖3-3系統(tǒng)用戶E-R圖數(shù)據(jù)管理局部E-R圖如圖3-4所示。圖3-4數(shù)據(jù)管理局部E-R圖醫(yī)院管理局部E-R圖如圖3-5所示。圖3-5醫(yī)院管理局部E-R圖訂單管理局部E-R圖如圖3-6所示圖3-6訂單管理局部E-R圖統(tǒng)計(jì)管理局部E-R圖如圖3-7所示圖3-7統(tǒng)計(jì)管理局部E-R圖醫(yī)院設(shè)置局部E-R圖如圖3-8所示圖3-8醫(yī)院設(shè)置局部E-R圖醫(yī)院管理局部E-R圖如圖3-9所示圖3-9醫(yī)院管理局部E-R圖科室列表局部E-R圖如圖3-10所示圖3-10科室列表局部E-R圖排班列表局部E-R圖如圖3-11所示圖3-11排班列表局部E-R圖系統(tǒng)總體E-R圖如圖3-12所示。圖3-12總體E-R圖3.3.2邏輯設(shè)計(jì)數(shù)據(jù)表的描述如下所示。（1）就診人表（編號(hào)，用戶id，姓名，證件類型，證件編號(hào)，性別，出生年月，手機(jī)，省code，市code，區(qū)code，詳情地址，狀態(tài)）。（2）用戶表（編號(hào)，微信openid，昵稱，手機(jī)號(hào)，用戶姓名，證件類型，認(rèn)證狀態(tài)，狀態(tài)）。（3）用戶登陸記錄表（編號(hào)，用戶id，ip）。（4）醫(yī)院設(shè)置表（編號(hào)，醫(yī)院名稱，醫(yī)院編號(hào)，ap基礎(chǔ)路徑，簽名密鑰，聯(lián)系人，聯(lián)系人手機(jī)，狀態(tài)）。（5）數(shù)據(jù)字典表（編號(hào)，上級(jí)id，名稱，值，編碼）。（6）訂單信息表（編號(hào)，用戶id，訂單交易號(hào)，醫(yī)院編號(hào)，醫(yī)院名稱，科室編號(hào)，醫(yī)生職稱，排班編號(hào)，安排日期，安排時(shí)間，就診人id，就診人名稱，就診人手機(jī)，訂單狀態(tài)）。（7）支付信息表（編號(hào)，對(duì)外業(yè)務(wù)編號(hào)，訂單id，支付類型，交易編號(hào)，支付金額，支付內(nèi)容，支付狀態(tài)）。（8）退款信息表（編號(hào)，對(duì)外業(yè)務(wù)編號(hào)，訂單編號(hào)，支付類型，交易編號(hào)，退款金額，退款狀態(tài)）。（9）醫(yī)院表（編號(hào)，醫(yī)院編號(hào)，醫(yī)院名稱，醫(yī)院類型，省編號(hào)，市編號(hào)，區(qū)域編號(hào)，醫(yī)院logo，醫(yī)院介紹）。（10）科室表（編號(hào)，醫(yī)院編號(hào)，科室編號(hào)，科室名稱，科室介紹，上級(jí)編號(hào)，上級(jí)名稱）（11）排班表（編號(hào)，醫(yī)院編號(hào)，科室編號(hào)，醫(yī)生類型，醫(yī)生姓名預(yù)約容量，可預(yù)約數(shù)，預(yù)約金額，狀態(tài)）。3.3.3物理設(shè)計(jì)數(shù)據(jù)庫的物理設(shè)計(jì)關(guān)系到數(shù)據(jù)庫的復(fù)雜程度以及性能，是數(shù)據(jù)庫設(shè)計(jì)中最關(guān)鍵的一步。預(yù)約掛號(hào)管理系統(tǒng)數(shù)據(jù)庫由MySQL關(guān)系型數(shù)據(jù)庫進(jìn)行設(shè)計(jì)，使用了Navicat對(duì)數(shù)據(jù)庫進(jìn)行操作管理。其11張表結(jié)構(gòu)如所示。就診人表結(jié)構(gòu)如表3-13所示。表3-1patient表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增user_idbigint用戶idnamevarchar20姓名certificates_typevarchar3證件類型certificates_novarchar30證件編號(hào)sexvarchar性別birthdatedate出生年月phonevarchar11手機(jī)province_codevarchar20省codecity_codevarchar20市codedistrct_codevarchar20區(qū)codeaddressvarchar100詳細(xì)地址contacts_namevarchar20聯(lián)系人姓名contacts_phonevarchar11聯(lián)系人手機(jī)statustinyint狀態(tài)(0:默認(rèn)，1:已認(rèn)證)（2）用戶信息表結(jié)構(gòu)如表3-14所示 表3-14user_info表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增openidvarchar100微信openidnick_namevarchar20昵稱phonevarchar100手機(jī)號(hào)namevarchar50用戶姓名certificates_typevarchar3證件類型statustinyint認(rèn)證狀態(tài)auth_statustinyint狀態(tài)(0:鎖定，1:狀態(tài))（3）用戶登陸記錄表結(jié)構(gòu)如表3-15所示 表3-15user_info_record表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增useridvarchar100微信openidnick_namevarchar20昵稱ipvarchar100手機(jī)號(hào)（4）醫(yī)院設(shè)置表結(jié)構(gòu)如表3-16所示表3-16hospital_set表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增hosnamevarchar100醫(yī)院名稱hoscodevarchar30醫(yī)院編號(hào)api_urlvarchar100Api基礎(chǔ)路徑sign_keyvarchar50簽名密鑰contacts_namevarchar20聯(lián)系人contacts_phonevarchar11聯(lián)系人電話statustinyint狀態(tài)（5）訂單信息表結(jié)構(gòu)如表3-17所示 表3-17order_info表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增useridvarchar100用戶idout_trade_novarchar20訂單編號(hào)hoscodevarchar100醫(yī)院編號(hào)hosnamevarchar50醫(yī)院名稱depnamevarchar3科室名稱titlevarchar30醫(yī)生職稱hos_schedule_idvarchar200排班編號(hào)reserve_datetinyint安排日期reserve_timetinyint安排時(shí)間patient_idtimetamp就診人idpatient_nametimetamp20就診人名稱patient_phonetinyint11就診人手機(jī)order_statustinyint訂單狀態(tài)（6）支付信息表結(jié)構(gòu)如表3-18所示 表3-18payment_info表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增out_trade_novarchar30對(duì)外業(yè)務(wù)編號(hào)order_idvarchar訂單idpayment_typevarchar1支付類型trade_novarchar50交易編號(hào)total_amountvarchar10支付金額subjectvarchar200交易內(nèi)容payment_statusvarchar支付狀態(tài)（7）退款信息表結(jié)構(gòu)如表3-19所示 表3-19refund_info表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增uut_trade_novarchar30對(duì)外業(yè)務(wù)編號(hào)order_idvarchar訂單idpayment_typevarchar1支付類型Trade_novarchar50交易編號(hào)total_amountvarchar10支付金額refund_statusvarchar30退款狀態(tài)（8）數(shù)據(jù)字典表結(jié)構(gòu)如表3-20所示。表3-20dict表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增parent_idbigint上級(jí)idnamevarchar100名稱valuebigint值dict_codevarchar20編碼（9）醫(yī)院信息表結(jié)構(gòu)如表3-21所示 表3-21hospital表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增hoscodevarchar100醫(yī)院編號(hào)hosnamevarchar50醫(yī)院名稱hostypevarchar10醫(yī)院類型provinceCodevarchar3省編號(hào)cityCodevarchar30市編號(hào)districtCodevarchar200區(qū)編號(hào)logoDatatinyint醫(yī)院logointrotimetamp醫(yī)院介紹（10）科室表結(jié)構(gòu)如表3-22所示 表3-22department表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增hoscodevarchar100醫(yī)院編號(hào)depcodevarchar50科室編號(hào)depnamevarchar10科室名稱introvarchar20科室介紹bigcodevarchar20上級(jí)編號(hào)bignamevarchar20上級(jí)名稱（11）排班表結(jié)構(gòu)如表3-23所示 表3-23schedule表結(jié)構(gòu)字段數(shù)據(jù)類型長(zhǎng)度主鍵/外鍵備注idbigint主鍵編號(hào)，自增hoscodevarchar100醫(yī)院編號(hào)depcodevarchar50科室編號(hào)titlevarchar10醫(yī)生類型decnamevarchar10醫(yī)生姓名availableNumberint可預(yù)約數(shù)amountint20預(yù)約金額statustinyint狀態(tài)3.3.4數(shù)據(jù)庫性能優(yōu)化數(shù)據(jù)庫性能優(yōu)化時(shí)間漫長(zhǎng)且需要實(shí)際驗(yàn)證,這其中涉及且需要我們考慮的因素很多,目前市面上的數(shù)據(jù)庫類型有比較的多，不同數(shù)據(jù)庫的優(yōu)化所涉及的東西也并不相同，所以我們只能針對(duì)性的對(duì)經(jīng)常用的數(shù)據(jù)庫做細(xì)致的性能優(yōu)化REF_Ref12343\r\h[10REF_Ref12356\r\h,11]。下面我就以mysql數(shù)據(jù)庫作為對(duì)象進(jìn)行性能優(yōu)化探討。數(shù)據(jù)庫的查詢操作在所有操作中占超50%以上，查詢的響應(yīng)時(shí)間將直接決定數(shù)據(jù)庫性能的強(qiáng)弱。除此之外，計(jì)算機(jī)的硬盤以及內(nèi)存也對(duì)數(shù)據(jù)庫的性能有較大影響，硬盤和內(nèi)存條越好的機(jī)器就越能發(fā)揮數(shù)據(jù)庫的性能。在實(shí)際的生產(chǎn)環(huán)境中，面臨海量的數(shù)據(jù)存儲(chǔ)，一個(gè)數(shù)據(jù)庫和一張表的存儲(chǔ)量和性能是有限的，其性能會(huì)隨數(shù)據(jù)增加將線性遞減。為了解決以上數(shù)據(jù)庫性能優(yōu)化問題。我們可以從以下幾點(diǎn)考慮：1、開啟查詢緩存，優(yōu)化查詢；2、當(dāng)只要一行數(shù)據(jù)時(shí)使用limit1；3、為搜索字段建索；4、根據(jù)業(yè)務(wù)數(shù)據(jù)量的大小選擇分庫分表3.4本章小結(jié)主要描述系統(tǒng)的總體設(shè)計(jì)，分別從系統(tǒng)的整體布局和系統(tǒng)的各個(gè)模塊的劃分進(jìn)行了概要闡述，同時(shí)對(duì)數(shù)據(jù)庫的不同層級(jí)的設(shè)計(jì)做出了E-R圖流程展示，

4詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)詳細(xì)設(shè)計(jì)需要實(shí)現(xiàn)設(shè)計(jì)的所有細(xì)節(jié)，包括系統(tǒng)開發(fā)、運(yùn)行環(huán)境描述、系統(tǒng)模塊的詳細(xì)實(shí)現(xiàn)和通過畫出流程圖為每一個(gè)模塊確定使用的步驟，畫出時(shí)序圖確定程序之間相互依賴關(guān)系。4.1開發(fā)及運(yùn)行環(huán)境描述系統(tǒng)的開發(fā)使用聯(lián)想小新電腦，運(yùn)行環(huán)境中前端使用Vue和ElementUI，運(yùn)行于Node12上，后端使用微服務(wù)，運(yùn)行于JDK1.8上，依賴管理工具使用Maven3.6.3。其它系統(tǒng)依賴組件則部署在云服務(wù)器上的Docker容器中。4.2實(shí)名認(rèn)證模塊流程圖如下圖4-1所示圖4-1實(shí)名認(rèn)證模塊功能流程圖時(shí)序圖如下圖4-2所示圖4-2實(shí)名認(rèn)證模塊時(shí)序圖4.3掛號(hào)訂單模塊流程圖如下圖4-3所示圖4-3掛號(hào)訂單模塊功能流程圖時(shí)序圖如下圖4-4所示圖4-4掛號(hào)訂單模塊時(shí)序圖4.4就診人管理模塊流程圖如下圖4-5所示圖4-5就診人管理模塊時(shí)序圖時(shí)序圖如下圖4-6所示圖4-6就診人管理模塊時(shí)序圖4.5注冊(cè)登錄模塊流程圖如下圖4-7所示圖4-7注冊(cè)登錄模塊時(shí)序圖時(shí)序圖如下圖4-8所示圖4-8注冊(cè)登錄模塊時(shí)序圖4.6用戶管理模塊流程圖如下圖4-9所示圖4-9用戶管理模塊功能流程圖時(shí)序圖如下圖4-10所示圖4-10用戶管理模塊時(shí)序圖4.7數(shù)據(jù)管理模塊流程圖如下圖4-11所示 圖4-11數(shù)據(jù)管理模塊功能流程圖時(shí)序圖如下圖4-12所示圖4-12數(shù)據(jù)管理模塊時(shí)序圖4.8醫(yī)院管理模塊流程圖如下圖4-13所示圖4-13醫(yī)院管理模塊功能流程圖時(shí)序圖如下圖4-14所示圖4-14醫(yī)院管理模塊時(shí)序圖4.9訂單管理模塊流程圖如下圖4-15所示圖4-15訂單管理模塊功能流程圖時(shí)序圖如下圖4-16所示圖4-16訂單管理模塊時(shí)序圖4.10統(tǒng)計(jì)管理模塊流程圖如下圖4-17所示圖4-17統(tǒng)計(jì)管理模塊功能流程圖時(shí)序圖如下圖4-18所示圖4-18統(tǒng)計(jì)管理模塊時(shí)序圖4.11醫(yī)院設(shè)置模塊流程圖如下圖4-19所示圖4-19醫(yī)院設(shè)置模塊功能流程圖時(shí)序圖如下圖4-20所示圖4-20醫(yī)院設(shè)置模塊時(shí)序圖4.12科室排班管理模塊流程圖如下圖4-21所示圖4-21科室排班管理模塊功能流程圖時(shí)序圖如下圖4-22所示圖4-22科室排班管理模塊時(shí)序圖4.13本章小結(jié)本章主要通過編碼、畫流程圖和時(shí)序圖以及實(shí)現(xiàn)過程中的思考感悟，讓我對(duì)系統(tǒng)的宏觀及微觀都有了更加深入的理解和掌握，也讓我對(duì)未來相似的設(shè)計(jì)實(shí)現(xiàn)有了寶貴的經(jīng)驗(yàn)。

5系統(tǒng)測(cè)試系統(tǒng)測(cè)試項(xiàng)目的最后保障，是對(duì)前面所有工作和編碼部分的最終審核，是保證項(xiàng)目質(zhì)量的重要手段。。5.1測(cè)試目的由于人的能力有一定的局限性，在軟件開發(fā)周期的過程中難免會(huì)考慮不周或犯些錯(cuò)誤，這些缺陷和錯(cuò)誤如果不及時(shí)糾正，會(huì)對(duì)用戶或軟件開發(fā)者造成一定的影響。通過修正各種錯(cuò)誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造成的隱患所帶來的商業(yè)風(fēng)險(xiǎn)。。5.2功能性測(cè)試檢查系統(tǒng)功能是否滿足產(chǎn)品需求規(guī)格說明書的要求，系統(tǒng)的各個(gè)功能是否可以保持無錯(cuò)誤，是產(chǎn)品可靠性的保障。下面將會(huì)對(duì)系統(tǒng)的三個(gè)平臺(tái)中的不同模塊分別進(jìn)行測(cè)試。5.2.1實(shí)名認(rèn)證模塊測(cè)試用例對(duì)平臺(tái)用戶實(shí)名認(rèn)證模塊中的用戶列表、認(rèn)證審核列表中的用戶詳情數(shù)據(jù)進(jìn)行在增刪查改相關(guān)操作。表5-1實(shí)名認(rèn)證模塊測(cè)試用例表用例編號(hào)1被測(cè)功能實(shí)名認(rèn)證功能描述實(shí)名認(rèn)證測(cè)試目的保證該實(shí)名認(rèn)證模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加認(rèn)證認(rèn)證添加添加成功2修改認(rèn)證認(rèn)證修改修改成功3刪除認(rèn)證認(rèn)證刪除刪除成功4查詢認(rèn)證認(rèn)證查詢查詢成功5.2.2掛號(hào)訂單模塊測(cè)試用例用戶對(duì)掛號(hào)訂單模塊中的訂單進(jìn)行查詢、刪除、查看、取消預(yù)約等相應(yīng)數(shù)據(jù)操作。表5-2掛號(hào)訂單模塊測(cè)試用例表用例編號(hào)2被測(cè)功能掛號(hào)訂單功能描述用戶進(jìn)行掛號(hào)訂單操作測(cè)試目的保證該掛號(hào)訂單模塊功能可以正常使用測(cè)試步驟查詢、刪除、修改、取消序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1查詢訂單掛號(hào)訂單查詢成功2修改訂單掛號(hào)訂單修改成功3刪除訂單掛號(hào)訂單刪除成功4取消預(yù)約掛號(hào)訂單取消成功5.2.3就診人管理模塊測(cè)試用例用戶對(duì)就診人管理模塊中的就診人進(jìn)行添加、刪除、修改等相應(yīng)數(shù)據(jù)操作。表5-3就診人管理模塊測(cè)試用例表用例編號(hào)3被測(cè)功能就診人管理功能描述用戶對(duì)就診人進(jìn)行管理測(cè)試目的保證該就診人管理模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加就診人就診人管理添加成功2修改就診人就診人管理修改成功3刪除就診人就診人管理刪除成功4查詢就診人就診人管理查詢成功5.2.4登陸注冊(cè)模塊測(cè)試用例用戶在登陸注冊(cè)模塊進(jìn)行手機(jī)號(hào)、微信掃碼登錄注冊(cè)登錄等相應(yīng)注冊(cè)登錄操作。表5-4注冊(cè)登錄模塊測(cè)試用例表用例編號(hào)4被測(cè)功能登陸注冊(cè)功能描述用戶進(jìn)行注冊(cè)登錄測(cè)試目的保證該登陸注冊(cè)模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、掃碼序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1輸入手機(jī)號(hào)注冊(cè)登錄添加成功2修改手機(jī)號(hào)注冊(cè)登錄修改成功3刪除手機(jī)號(hào)注冊(cè)登錄刪除成功4微信掃碼注冊(cè)登錄登錄成功5.2.5用戶管理模塊測(cè)試用例系統(tǒng)管理員對(duì)用戶管理模塊中的用戶列表、認(rèn)證審核列表中的用戶詳情數(shù)據(jù)進(jìn)行在增刪查改相關(guān)操作。表5-1用戶管理模塊測(cè)試用例表用例編號(hào)5被測(cè)功能用戶管理功能描述系統(tǒng)管理員可以管理用戶以及用戶認(rèn)證測(cè)試目的保證該模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢、審批、鎖定、清空序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加用戶用戶列表添加成功2刪除用戶用戶列表刪除成功3修改用戶用戶列表修改成功4查詢用戶用戶列表查詢成功5查詢認(rèn)證認(rèn)證列表查詢成功6審批通過認(rèn)證列表認(rèn)證成功7審批拒絕認(rèn)證列表認(rèn)證失敗8鎖定用戶用戶列表鎖定成功9取消鎖定用戶列表取消鎖定成功10清空條件選擇用戶列表清空成功5.2.6數(shù)據(jù)管理模塊測(cè)試用例系統(tǒng)管理員對(duì)數(shù)據(jù)管理模塊中的數(shù)據(jù)字典列表進(jìn)行查看、導(dǎo)入、導(dǎo)出等相關(guān)操作。表5-2數(shù)據(jù)管理模塊測(cè)試用例表用例編號(hào)6被測(cè)功能數(shù)據(jù)管理功能描述系統(tǒng)管理員可以管理數(shù)據(jù)字典測(cè)試目的保證該數(shù)據(jù)管理模塊功能可以正常使用測(cè)試步驟導(dǎo)入、導(dǎo)出、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1導(dǎo)入字典數(shù)據(jù)字典導(dǎo)入成功2導(dǎo)出字典數(shù)據(jù)字典導(dǎo)出成功3查詢字典數(shù)據(jù)字典查詢成功4點(diǎn)擊省數(shù)據(jù)字典顯示省級(jí)列表5點(diǎn)擊醫(yī)院等級(jí)數(shù)據(jù)字典顯示醫(yī)院級(jí)別6點(diǎn)擊二級(jí)菜單數(shù)據(jù)字典顯示二級(jí)目錄5.2.7醫(yī)院管理模塊測(cè)試用例系統(tǒng)管理員對(duì)醫(yī)院管理模塊中的醫(yī)院設(shè)置、醫(yī)院列表中的醫(yī)院數(shù)據(jù)進(jìn)行在增刪查改等相關(guān)操作。表5-3醫(yī)院管理模塊測(cè)試用例表用例編號(hào)7被測(cè)功能醫(yī)院管理功能描述系統(tǒng)管理員可以進(jìn)行醫(yī)院管理測(cè)試目的保證該醫(yī)院管理模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加醫(yī)院醫(yī)院管理添加成功2修改醫(yī)院醫(yī)院管理修改成功3刪除醫(yī)院醫(yī)院管理刪除成功4查詢醫(yī)院醫(yī)院管理添加成功5.2.8訂單管理模塊測(cè)試用例系統(tǒng)管理員對(duì)訂單管理模塊中的訂單列表中的訂單數(shù)據(jù)進(jìn)行在增刪查改等相關(guān)操作。表5-4訂單管理模塊測(cè)試用例表用例編號(hào)8被測(cè)功能訂單管理功能描述系統(tǒng)管理員可以進(jìn)行訂單管理測(cè)試目的保證該功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加訂單訂單管理添加成功2修改訂單訂單管理修改成功刪除訂單訂單管理刪除成功3添加訂單訂單管理添加成功5.2.9統(tǒng)計(jì)管理模塊測(cè)試用例系統(tǒng)管理員對(duì)統(tǒng)計(jì)管理模塊中的預(yù)約統(tǒng)計(jì)中的預(yù)約數(shù)據(jù)進(jìn)行在查看操作。表5-5統(tǒng)計(jì)管理模塊測(cè)試用例表用例編號(hào)9被測(cè)功能統(tǒng)計(jì)管理功能描述系統(tǒng)管理員可以進(jìn)行統(tǒng)計(jì)管理測(cè)試目的保證統(tǒng)計(jì)功能正常測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加統(tǒng)計(jì)統(tǒng)計(jì)管理添加成功2修改統(tǒng)計(jì)統(tǒng)計(jì)管理修改成功3刪除統(tǒng)計(jì)統(tǒng)計(jì)管理刪除成功4查詢統(tǒng)計(jì)統(tǒng)計(jì)管理添加成功5.2.10醫(yī)院設(shè)置模塊測(cè)試用例醫(yī)院對(duì)接人員對(duì)醫(yī)院設(shè)置模塊中的醫(yī)院編號(hào)、簽名key、接入地址進(jìn)行操作。表5-10醫(yī)院設(shè)置模塊測(cè)試用例表用例編號(hào)10被測(cè)功能醫(yī)院設(shè)置功能描述對(duì)接人員可以進(jìn)行醫(yī)院設(shè)置測(cè)試目的保證該醫(yī)院設(shè)置模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加醫(yī)院code醫(yī)院設(shè)置添加成功2添加醫(yī)院簽名醫(yī)院設(shè)置添加成功3添加接入地址醫(yī)院設(shè)置添加成功4修改醫(yī)院code醫(yī)院設(shè)置修改成功5修改醫(yī)院簽名醫(yī)院設(shè)置修改成功6修改接入地址醫(yī)院設(shè)置修改成功5.2.11科室排班模塊測(cè)試用例醫(yī)院對(duì)接人員對(duì)科室排班模塊中的科室、排班數(shù)據(jù)進(jìn)行添加、刪除等操作。表5-11科室排班模塊測(cè)試用例表用例編號(hào)11被測(cè)功能科室排班功能描述對(duì)接人員可以進(jìn)行科室排班管理測(cè)試目的保證該科室排班模塊功能可以正常使用測(cè)試步驟添加、刪除、修改、查詢序號(hào)輸入數(shù)據(jù)/動(dòng)作測(cè)試點(diǎn)預(yù)期結(jié)果1添加科室科室列表添加成功2修改科室科室列表修改成功3刪除科室科室列表刪除成功4查詢科室科室列表查詢成功5添加排班排班列表添加成功6修改排班排班列表修改成功7刪除排班排班列表刪除成功8查詢排班排班列表查詢成功5.3非功能性測(cè)試（1）界面多端適配性，通過在不同電子設(shè)備之間進(jìn)行切換，整個(gè)系統(tǒng)平臺(tái)的界面任然可以展現(xiàn)出客觀可用的效果，在不同平臺(tái)可以很好的適配。（2）穩(wěn)定安全性，通過Jmeter測(cè)試工具，模擬一秒內(nèi)1000次的同時(shí)訪問，服務(wù)器任然可以安全穩(wěn)定的工作。（3）易用擴(kuò)展性，通過自己和室友等幾人的實(shí)際使用在易用性方面有不錯(cuò)的效果，由于采用微服務(wù)加模塊化設(shè)計(jì)所以在擴(kuò)展性方面比較優(yōu)秀。5.4本章小結(jié)本章從功能性和非功能性兩方面分析了系統(tǒng)測(cè)試的過程，再對(duì)系統(tǒng)每個(gè)功能模塊進(jìn)行功能性和非功能性能測(cè)試，并通過測(cè)試用例的形式清楚地記錄下來。通過系統(tǒng)測(cè)試可以發(fā)