基于SSM框架下殘疾家教平臺的開發

周耀　韋忠亮

關鍵詞：家教平臺；Vue；SSM；Java；MySQL

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2023）12-0060-04

0 引言

中國的殘疾教育目前呈發展態勢，從新中國成立初期時僅能對視覺障礙兒童和聽覺障礙兒童提供最基本的教育到現在實現了全面覆蓋，實現對不同的殘疾兒童提供相對應的教育形式。與此同時殘疾兒童義務教育的普及程度不斷提高，普及程度的提高不僅表明接受基礎義務教育的人數增加也包括接受教育的學生類別有所拓展。目前我國在現有的特殊教育體系層次上已經具備了學前教育、義務教育、高中教育及高等教育的所有階段，同時也具備了基礎教育、職業教育、成人教育等類型，保證了類型的全覆蓋[1]。

由于特殊教育水平的不斷提高，由此也帶來很多的問題。其中教育水平的差異成為一個較為突出的問題。問題產生的主要原因在于欠發達地區和發達地區所擁有的特殊教師數量和質量不匹配使得殘疾兒童所受到的教育質量和水平也不匹配[2]。

殘疾人家教服務平臺（以下簡稱“家教平臺”） 正是為了解決該問題而研究開發。家教平臺為特殊學校的學生提供服務，通過家教平臺，學生可以瀏覽各地的名師資源，尋找合適的教師。同時平臺也為教師提供了就業的幫助。通過家教平臺，可以在一定程度上緩解教育水平不平衡的矛盾。同時平臺也提供網上教學或者線下教學。線上教學的流行，是一種輔助傳統教學的手段，將信息技術應用到教學中，可以極大地拉近學生和老師的距離。為學生的學習和老師的教學提供便利[3]。家教平臺將該理念引入，提供了線上的教學平臺。

1 系統分析

1.1 業務分析

對于特殊家教的家教平臺來說，其擁有三個主體，一是用戶，二是教師，三是系統。用戶將所需要的家教信息輸入系統，系統會根據用戶的具體權限以及其填寫的家教信息進行相應的匹配，其中還會檢測用戶的賬戶信息，確定具體的價格范圍，最后將匹配出的結果返回給用戶并完成此次匹配。其中主要的交互為用戶與系統的交互。

用戶通過填寫所需的家教信息向系統申請匹配，此時系統會獲取用戶的權限等級，接著接收申請，進行匹配，如果匹配成功則將信息展示給用戶，用戶進行選擇合適的家教老師，用戶選擇之后提交給系統此時會產生訂單，系統再將訂單交給用戶由用戶進行付款，即調取用戶的賬戶信息。用戶付款之后，系統確認接受訂單，并且通知教師該訂單，最后活動結束，教師信息在最開始便已經添加至教師信息庫。具體活動如圖1所示。

1.2 需求分析

用戶系統。當用戶進入平臺時，平臺會檢測用戶的權限，初始的用戶擁有最基本的權限即查看平臺的教師信息以及發布家教信息，但是不具備加速尋找教師功能以及觀看付費課程等功能。用戶需要通過平臺的權限升級系統進行相應的權限升級才可以使用上述功能。

教師系統。該模塊的功能主要為教師管理。當用戶選擇成為教師時，可以通過填寫教師申請，當平臺通過教師申請時，會將該用戶所填寫的教師信息傳輸至服務器，由服務器進行保存至教師信息庫，教師可以在該模塊中修改自身的教師信息，以及查看自身的訂單、評價等。

查詢系統。該模塊的功能為教師信息的查詢，當用戶需要在教師信息庫查詢信息時，可以借助該模塊。用戶可以通過教師名，教師ID進行指定教師的查詢，也可以通過姓氏、教師的科目以及教師學歷和教授年級進行范圍內查找，找尋出的教師會通過列表的方式進行展示。

訂單系統。該模塊的功能為訂單的生成、支付、確認以及通知。當用戶通過查詢子系統找到教師或者通過發布家教信息進入信息池找到教師，都需要經過訂單管理系統進行生成訂單，生成的訂單會交付給用戶，調用訂單支付系統進行支付，當用戶支付之后，訂單系統會確認該訂單，將此訂單進行快照，將快照后的訂單存入服務器端。具體用例圖如圖2所示。

2 系統設計

2.1 系統架構設計

家教平臺用戶視圖使用Vue框架搭建。Vue框架是一套用于構建用戶界面的漸進式框架。核心類庫只被視圖層使用[4]。服務器端由四個系統構成，分別為用戶系統、教師系統、查詢系統以及訂單系統。每一個系統中又分為具體的子系統。例如用戶系統分為權限驗證系統、登錄注冊系統以及個人中心系統等。具體如圖3所示。

服務器端相連接的數據庫使用MyBatis技術進行管理。MyBatis技術是用來對數據進行持久化處理，代替了JDBC的功能，在SSM框架中也是非常重要的一環。利用XML文件配置即可定義相應的方法，并且簡單，不依賴組件[5]。

現對家教平臺系統的設計做詳細闡述。

1） 用戶系統架構設計

家教平臺的核心是用戶，所以用戶系統是平臺的核心系統之一。如何構建用戶系統，需要進行分析。用戶系統分為兩個部分。首先是用戶的登錄和注冊，雖然是基礎的功能，但將其獨立為一個部分是為了不讓其受其他部分的影響。該部分完成用戶信息的收集，同時也需要完成用戶權限的驗證。其次是用戶的個人中心部分，該部分提供用戶查詢自身的資料，自身的訂單以及自身的收藏等。同時需要提供以上信息的修改和刪除操作，例如用戶可以修改自身的資料，刪除自身的訂單以及收藏等。同時用戶系統也提供了發布家教信息的功能，之所以將發布家教信息功能歸類在用戶系統架構中，一是為了節省系統資源，二是為了方便用戶信息的統一管理和存儲。

2） 查詢系統架構設計

查詢系統是平臺的支撐系統，通過查詢系統，用戶才能從教師信息庫中查詢相應的教師，不管是自定義查詢，還是范圍內查詢還是指定查詢，都能夠通過查詢系統進行實現。查詢系統主要是集合了很多的查詢方法，通過用戶的選擇調用不同的查詢方法，也是使用最頻繁的一個功能。上述的用戶系統也需要該系統的支持才能正常工作，因為用戶系統的個人中心部分也是需要查詢自身的資料、訂單和收藏，所以查詢系統是整個平臺的支撐系統。那么查詢系統如何組成呢？查詢系統分為兩部分，一部分是數據選擇區，另一部分是數據查詢區。數據選擇區指的是用戶所設置的查詢條件。例如用戶選擇了指定查詢，那么數據選擇區就需要將其指定的條件獲取，并且交付給數據查詢區進行查詢，數據查詢區查詢出結果之后將結果返回，最后交付前端頁面進行相應的處理。

3） 訂單系統架構設計

訂單系統作為家教平臺的核心系統之一，該部分提供了用戶支付功能，同時提供了對訂單的管理功能。訂單系統是家教平臺最為復雜的一個系統，其復雜的地方在于對訂單進行監視并且需要對接第三方支付接口，同時需要處理訂單在不同狀態下系統的作為。訂單系統分為以下幾個部分：第一部分是訂單生成部分。該部分的主要功能是生成訂單，一般會在用戶點擊教師頁面的下單按鈕時觸發該部分。

第二部分是訂單支付管理部分，也是訂單系統的核心部分。該部分對接了微信支付平臺接口以及支付寶支付平臺的接口。用戶可以選擇不同的支付平臺進行支付。該部分同時監測訂單的狀態，訂單是否已經超時，訂單是否已經支付，訂單是否已經提交等。當訂單處于不同的狀態時，該部分所操縱訂單系統的行為是不同的。

訂單系統的第三部分是訂單交付部分。當訂單支付管理部分提交已支付訂單時，該部分被觸發，該部分會接收已支付訂單，并將其快照存儲，然后通知用戶訂單處理成功，并且該部分會調用通知，通知教師已被下單，盡快地聯系下單方所提供的聯系方式。

訂單系統的第四部分是訂單異常處理部分。此部分當訂單出現異常狀況時才會被觸發。例如當用戶惡意地添加多個訂單，但并不支付，這是在損耗系統的資源，在此狀態下會觸發該部分，該部分會關閉該用戶的所有訂單，并且全部進行清除，但不會清除已支付的訂單。并對用戶進行警告。

以上就是訂單系統的四個部分。通過這四個部分的合作共同組成了一個完整的訂單系統，同時訂單系統會向其他的系統提供相應的數據，幫助其他系統完成其自身的業務功能。

4） 教師系統架構分析

教師系統作為平臺的核心系統之一，主要的任務是管理教師的申請以及教師信息的更改。所以教師系統可以分成兩個部分，第一部分是教師申請部分，第二部分是教師信息管理部分。用戶可以通過第一部分進行教師的申請，通過后該部分會將用戶所填寫的信息交付教師信息庫。成為教師后，可以通過第二部分進行教師信息的修改，該部分會將修改后的信息交付給教師信息庫并更新該教師的數據。

2.2 系統數據庫設計

1） 用戶信息表（用戶ID，用戶名，密碼，用戶頭像，昵稱，真實姓名，用戶手機，用戶郵箱，性別，用戶生日，注冊時間，更新時間，用戶角色，頭像保存路徑）

2） 教師信息表（教師ID，教師姓名，教齡，時薪，教授年級，教授學科，目前的學歷，目前的職業，所學專業，畢業院校，簡介，身份證號，是否通過驗證，教師圖片，教師的分類信息）

3） 教師詳細信息表（教師的訂單量，教師的推薦指數，教師的評價指數）

4） 訂單表（訂單ID，訂單狀態，訂單的用戶名稱快照，訂單的用戶地址快照，訂單的用戶手機快照，訂單的發起時間，訂單的確認時間，訂單的價格，訂單的優惠價格，訂單的實際支付價格，訂單號）

5） 訂單項表（訂單項ID，訂單ID，下單教師名稱，教學科目，教學年級，教學類型，教學起始時間，教學結束時間，時薪，備注）

6） 用戶收藏表（收藏ID，用戶ID，教師ID） 根據其邏輯結構將家教平臺的數據庫分為以下表，用戶信息表（user） ，教師信息表（teacher_info） ，教師詳細信息表（teachertParams） ，訂單表（order） 以及用戶的收藏表（collection） ，其主鍵均為ID。

3 系統實現

3.1 用戶系統實現

對于基礎的注冊和登錄功能，家教平臺采用的是前后端分離模式，所以并不使用傳統的方式進行驗證。而是采用axios異步通信技術向后端服務器進行傳值，通過后端服務器進行驗證。無論驗證成功或者失敗都會向頁面返回響應值，頁面通過讀取所返回的值來進行判斷是否成功，再顯示不同的內容。

個人中心是用戶所管理自身數據的一個模塊。在個人中心中，用戶可以查看頭像并且修改，也可以查看自己的基本資料并且可以修改自己的基本資料。同時，用戶可以查看自己所收藏的老師和自己所發布的家教信息。三個查看功能的基本邏輯相同，都是將用戶ID發送至服務器端，由服務器端持久層查詢數據庫中的數據并返回給前端頁面。由前端頁面進行展示。而修改資料則是通過前端頁面將表單數據發送給服務器端，由服務器端持久層修改數據庫中相應表的字段。具體流程如圖4所示。

發布家教信息是用戶尋找到家教老師的一個重要的手段。發布家教信息的流程是在表單的填寫之后，將表單所填寫的數據通過axios打包發送至服務器端，再通過一個實體類對象進行接收，在接收之后，通過持久層進行數據庫的插入，插入成功后返回完成消息，前端頁面接收后調用相應的函數進行彈窗提醒用戶發布家教信息成功。

3.2 查詢系統實現

作為家教平臺的核心功能，查詢教師信息庫是用戶尋找家教老師的另一重要手段。教師信息庫的設定是通過主頁的分類進行設計。在家教平臺的主頁面提供了教師的分類，該功能的實現較為煩瑣。當用戶在首頁點擊相應的分類時，需要跳轉到教員庫界面，同時在教員庫中提供了搜索功能，通過用戶所輸入的教師姓名進行查詢。具體流程圖如圖5所示。

3.3 訂單系統實現

訂單系統是家教平臺的核心系統。通過訂單系統用戶可以支付訂單，當用戶點擊相應的按鈕時會觸發系統生成相應的訂單，并且交付給用戶，用戶支付之后訂單系統會確認訂單，并且將該訂單存入數據庫中，具體流程如圖6所示。

3.4 教師系統實現

教師系統作為家教平臺的核心系統，其主要功能是提交教師的申請以及修改教師信息，而教師信息的修改和個人中心信息的修改類似。如圖7所示，為教師系統的流程圖，展示了教師系統的工作方式。

教師個人中心的搭建和用戶系統的個人中心相同，都是通過element-ui所提供的導航欄進行搭建。其同樣需要查詢系統的支持。通過查詢系統查詢教師自身的信息，訂單以及展示用戶對其的評價。評價高的可以在家教平臺的首頁進行展示推薦。

4 系統測試

白盒測試是用于對軟件各部分的邏輯進行測試，將軟件比作一個透明的盒子，其內部所有的運行邏輯和方式都展現在測試人員的面前，軟件測試人員對軟件的每一部分進行對應的測試，需要保證每一部分的邏輯都完全正確并且最終的結果也必須符合預期，該測試主要用于軟件或程序驗證。家教平臺的具體流程圖如圖8所示。

由圖可知該系統有11個可執行語句，有3個判斷框，同時有11條路徑。無論是用戶還是教師都需要進行身份判定才能進入系統，系統的功能模塊沒有先后關系，只有權限的不同，但是不會使系統的功能模塊出現先后順序的調用。具體如表1所示。

5 結束語

本文對家教平臺從概念設計到系統實現作出了一個簡單明了的闡述，為實現該平臺設計了系統模塊的概念。通過不同系統之間的相互通信和分工合作，達到服務用戶的目的。并且本系統的風格具有事件驅動風格以及管道-過濾器風格的結合。每一個系統都可以看作一個過濾器，而數據的傳遞則是通過管道進行實現。用戶的每一個需求操作都將被轉化為一個驅動事件，驅使系統執行相應的任務。