火車票管理系統團伙作案心得體會，也是非常寶貴的財富
更新時間：2023-08-03 17:04:00作者：佚名
【課程設計】數據庫：高鐵票管理系統
摘要：本文主要介紹了高鐵票管理系統火車票預訂時間表，其中包括其選題功能緒論，對該系統的方案方式設計，以及過程實現等內容。因為系統的代碼量較大，所以將要較為具象地對思想進行介紹，在必要時會列舉一些例子，都會附上成果展示以及安裝步驟。最后補充一下此次結伙作案的心得感受，只是十分寶貴的財富。
文章目錄
序言——起因與動力
本系統是由五位華工師生（劉老師、陳老師、羅老師、魯老師、盧老師）在閑暇時間中對數據庫課程設計進行的一次嘗試。緣由在于，盡管我們都有部份項目經驗，因此通常狀況下，都是由導師為我們所引導安排去施行任務的，所以在此課程下來后，我們就商量著感受一次，從零開始的自主實現項目過程。此次課設為對我們自身的增強有巨大的幫助，因此希望通過這篇文章分享下來。
對于該課設，對于我們的要求就是認真執行，定期舉辦組會與項目初驗。在開發過程中，嘗試了新的語言、開發工具以及開發方式等。其中最為印象深刻的是項目的集體討論設計的過程、語雀gitee等協同開發工具、函數插口的注釋標準化等細節內容、前端開發等初嘗試。很多都是先前淡淡嘗試過的內容，在本次課設中有了更豐富的知識獲取。
其實，因為是第一次做這么大的安裝工程，也遇見了一些困難的地方，例如在最初的數據庫設定完成后，課設舉行了一段時間，卻發覺設計內容還要更改，此刻更改安裝工程量較大，難免會出現一些焦慮情緒，當工作周期長時，也會出現部份拖沓松懈，在小組之間的鼓勵與監督下，完成讓課設繼續進行。可惜的是對于本系統因為時間較短，雖然是開發并不完整的，并且存在并發性以及部份插入的等問題，然而此次課設感受十分難得，學到了許多課堂需不到的內容。
一、選題背景
本課題是實現對高鐵票購票的管理系統，具備檢票系統、系統管理、綜合查詢等功能。該系統分為三大版塊，分別為檢票系統、系統管理和產值對賬。以下是每位模塊具體介紹。
二、方案論證（設計觀念）2.1運行和開發環境2.2面向對象編程
面向對象編程的優勢在于易維護、開發效率高和易擴充等，對于易維護，只需維護局部模塊，維護上去是十分便捷和費用較低；對于開發效率高，在硬件開發時，按照設計的還要對現實世界的事物進行具象，形成類，通過對類的封裝，對其的使用開發的效率和品質；易擴充因為承繼、封裝、多態的特征，自然設計出高內聚、低耦合的系統結構，并且系統更靈活、更容易擴充，但是費用較低。
后端面向對象編程展現于，每位界面的每位組件都設計為一個類，例如在管理端的用戶信息展示窗口中，首先對分欄器、用戶信息欄、搜索框進行父類封裝，在承繼后，通過多態的編程思想，進行再封裝，最后裝配在一起。
前端面向對象編程展現于，對于數據庫通過邏輯結構設計后，可以剖析出各個實體類，進行面對對象的編程。除了這般，因為設計部份工具操作，還額外定義了工具類，作為后端的輔助工具插口類。
2.3前后端分離
對于前后端分離，可以提升工作效率，分工愈發明晰。兩端開發可以同時進行，只需通過插口完成聯結，雙方互不干擾。而且為了在該次大作業中增加每個成員的參與度，所以在任務分配上，每位人就會有對前后端的工作安排。
2.4數據庫設計思路2.4.1需求剖析
用戶登入注冊：用戶包括工作人員和旅客，有管理員、售票員、乘客3類用戶；普通人可以通過注冊功能成為新用戶，用戶通過登陸可以使用系統提供的相應功能，如添加旅客，訂購船票，查詢訂單等等。
系統還要提供查詢火車具體信息的功能：用戶按照始發站和終點站，查詢可以滿足自己行程要求使得正常運行的動車，使得可以逐步查看駕車時間，抵達時間以及火車剩余坐位的數目和票價；用戶可以搜索詳細的某一趟車次，可以得到該車次的詳細路線信息以及發車時間。
系統還要提供購票功能：購票員鍵入站點即可顯示經過該站點的所有可售班次以及班次汽車的坐位狀態；一個檢票員可同時售數張相似或不同站點，相似或不同票種（一等、二等、站票）的船票，可以實現累加本次購票款，直到上次新檢票開始；還應實現輔助提示應找款以及退款的功能，購票員可以查詢當日購票賬單，旅客也可以通過互聯網售票。
系統還要提供管理功能：包括用戶管理、線路設置、站點設置、票價設置等。該系統主要分為四大部份，分別為用戶、車票、車次和路線版塊，每位版塊可以進行查詢與更改操作，管理員可以添加、修改和刪掉用戶信息、線路信息、車票信息以及車次信息。
系統還要提供產值對賬功能：包括購票員對賬、匯總報表。對營銷毀款進行管理，可以實時把握西站產值狀況，便于財務監督。才能迅速、準確地生成各類產值對賬報表。匯總報表主要包括：按照用戶選擇或則鍵入的各類條件（包括：時間，購票員，票號等）匯總北站營運數據，包括：售票匯總，改簽匯總，預購票匯總，廢票匯總，綜合匯總，財務匯總火車票預訂時間表，檢票員對賬單等等。
系統還要提供綜合查詢功能：包括：匯總線路、站點、班線、班次等各類基礎數據；統計運營數據，生成日報表、月報表和任意時段報表；以匯總表方式，顯示轉讓票張數、售票總額以及購票狀況。
2.4.2概念結構設計admin管理員、user用戶、售票員實體：在該實體中，用戶id為字段，拿來作為每一個用戶的惟一標志，同時也作為登錄系統的用戶名使用；身分屬性適于辨別用戶的類別，1為普通用戶，2為管理員，3為檢票員；每位用戶都有惟一的身分證號和電話號碼。
route路線實體：在該實體中，路線id為字段，拿來作為每一條路線的惟一標志，另外還記錄了該路線途徑的每一站以及抵達該站的時刻。
train車次實體：在該實體中，車次id為字段，拿來作為每一個車次的惟一標志；不同車次的火車擁有自己的一等座人數、二等座人數和三等座人數；路線id作為該實體的主鍵與路線表相聯系，該車次的一等座、二等座以及三等座的售價也通過對應路線的耗時和價錢參數估算下來。
船票實體：在該實體中，車次id和發車日期作為聯合字段，車次id作為主鍵與車次表相關聯；一等座、二等座以及三等座剩余人數分別記錄了某一車次某一日期當日的不同船票類別的剩余人數。
用戶訂單實體：在該實體中，訂單id作為鍵值，拿來作為每一份訂單的惟一標志；對于每一份獨立的訂單，記錄著用戶訂購某一張船票的所有信息：包括用戶身分證號、購買車次id、車票類別（一等座、二等座和三等座）、該船票的售價、下單時間、起始站、終點站、出發時間、賬單id以及是否發生退款行為（1為發生了訂票2為未發生訂票）；其中車次id作為該實體類別的字段與車次表相關聯，可以對應到相關車次的詳細信息。
bill用戶帳單實體：在該實體中，帳單id作為字段，拿來作為每一份帳單的惟一標志；購票員id作為主鍵與用戶表相關聯，且該用戶身分屬性的值為3，代表著該帳單對應的某一個檢票員；訂單id作為主鍵與訂單表相關聯，適于記錄該訂單屬于某一帳單，一份帳單可以對應到多份訂單；因此該實體還包括應付總額和實付總額這兩個屬性，通過這兩個屬性可以估算出找零總額。
整體E-R圖
2.4.3邏輯結構設計
實體轉換為關系機制
用戶信息（用戶id，電話號碼，密碼，身分證號，真實姓名，用戶類別，性別，注冊日期）
路線信息（路線id，出發時間，抵達時間，出發站，目的站，后邊站1，后邊站2，后邊站3，后邊站4，后邊站5，后邊站6，后邊站7，后邊站8，抵達時間1，抵達時間2，抵達時間3，抵達時間4，抵達時間5，抵達時間6，抵達時間7，抵達時間8）
車次信息（車次id，路線id，一等座人數，二等座人數，三等座人數，一等票售價，二等票售價，三等票售價）
船票信息（車次id，發車日期，一等座剩余人數，二等座剩余人數，三等座剩余人數）
訂單信息（訂單id，用戶身分證號，帳單id，車次id，船票類別，售價，下單時間，發車時間，出發地，目的地，是否訂票）
帳單信息（帳單id，訂單id，購票員id，實付總額，應付總額）
聯系轉換為關系機制
用戶擁有訂單（用戶身分證號，訂單編號）
訂單擁有車次（訂單編號，車次編號）
火車擁有路線信息（車次編號，路線編號）
帳單擁有訂單（帳單編號，訂單編號）
帳單對應購票員（帳單編號，購票員編號）
船票擁有車次（車次編號，發車日期）
實體與聯系進行合并
User表設計如下：
Route表設計如下：
Train表設計如下：
表設計如下：
表設計如下：
Bill表設計如下：
2.5硬件框架與步驟
該大作業的硬件框架分為三層，為表現層、應用層與數據層。表現層主要功能為數據修飾及展示、獲取用戶信息、發送數據訪問懇求；應用層主要功能為相應訪問懇求、提供數據訪問插口、嵌入式數據庫編程、數據封裝更改；數據層主要功能為數據庫設計、數據初始化、儲存、增刪查改。工具箱為整個爭創開發過程提供相應工具，以便開發進行。
程序步驟設置為從登錄界面踏入，可以從登錄界面中選擇打開注冊界面完成注冊，還可以選擇身分，完成登入操作，踏入用戶界面、售票員界面以及管理員界面。其中管理員界面可以打開匯總界面，查看銷售狀況。對于用戶界面、售票員界面以及管理員界面，都是采取訪問應答的形式獲取數據并完成數據整理展示到后端，而匯總界面，這是依據當晚的購票狀況，獲取相應數據并完成整理與展示。
2.6后端設計
管理員界面：分為三大版塊，分別為標題區、功能選擇區以及顯示區，標題區會對硬件的信息和字體進行展示，并提供用戶的基本信息；功能選擇區將要對管理層的功能進行分類，并通過標簽顯示，由鍵盤單擊來確定數據顯示界面；顯示區則是對前端數據傳到后，對數據完成整理并進行展示。
購票員界面：分為三大版塊，分別為標題區、售票區以及帳單遞交區，標題區會對硬件的信息和字體進行展示，并提供購票員的基本信息；購票區可以由購票員鍵入目的站和終點站對符合條件的車次信息進行查找并顯示；帳單遞交區則是對購票員處理的一系列訂單進行遞交操作。
用戶界面：該界面與檢票員界面相同，分為三大版塊，分別為標題區、售票區以及帳單遞交區，標題區會對硬件的信息和字體進行展示，并提供購票員的基本信息；購票區可以由購票員鍵入目的站和終點站對符合條件的車次信息進行查找并顯示；帳單遞交區則是對購票員處理的一系列訂單進行遞交操作。
三、過程闡述
因為系統內容較大，所以在此介紹過程闡述的大體思路，必要時進行詳細樣例的說明。而更具體的內容會可以通過分工，詳細查看每個成員的試驗報告，上面包括了詳細的代碼實現方法。
3.1任務分工
后端
前端
3.2整體框架
設置為從登錄界面踏入，可以從登錄界面中選擇打開注冊界面完成注冊，還可以選擇身分，完成登入操作，踏入用戶界面、售票員界面以及管理員界面。其中管理員界面可以打開匯總界面，查看銷售狀況。對于用戶界面、售票員界面以及管理員界面，都是采取訪問應答的形式獲取數據并完成數據整理展示到后端，而匯總界面，這是依據當晚的購票狀況，獲取相應數據并完成整理與展示。
3.3后端開發
樣例：此處列舉車次信息查看窗口，該窗口由分欄器、搜索框以及信息展示三個組件進行構成。其中分欄器是直接通過ui生成代碼，再通過編譯器完成封裝，直接使用的。對于搜索框與信息展示欄，我們通過ui生成后，進行父類封裝，再承繼父類內容，完成多態封裝，在此產生符合列車信息查看的組件要求。再通過布局將各個組件組合上去。
3.4圖表描繪
詳細實現方式：
3.5前后端交互
需求功能實現方法：首先在ui界面中查看是否數據違法或填寫信息不完全，再者應用層從數據層獲取數據進行處理，再與后端數據比較或交互等操作，最后完成業務功能。
在此進行一個樣例說明：在后端發送獲取報表信息的懇求后，后端會對信息進行檢測，假如正確會傳到到前端中，通過服務層進行數據的估算處理與封裝，最后傳回給后端。或許在過程中使用了工具系列的其他方式，當發生錯誤時，將要對錯誤信息進行報錯。
3.6應用層插口
應用功能實現方法：從數據層中獲取對應數據，再者應用層從數據層獲取數據進行處理，對數據進行估算統計與整理判定數據生成是否成功，進行相應的提示，并傳輸生成后的數據。
詳細樣例為：在統計前五名的購票員產量時，首先在數據層獲取數據并進行相應的整理，在到應用層中處理數據，最后將數據返回，并提示對應信息
3.7數據庫編程
數據庫連結操作：此處使用了json文件進行配置，其中補充了關于數據庫連結的各類信息，詳細代碼如下：
數據庫的插口整體框架：首先會判定傳到參數的正確性，例如寬度與違法字符等再者通過字符串條紋的形式，將mysql句子完成條紋，成后通過游標進行執行假如成功則復印提示信息，假如失敗將要拋出異常，同時進行數據庫的回滾操作。
四、成果展示（部份）4.1登入界面
登陸界面ui圖
檢測填入信息合法性
權限不足提示
4.2注冊界面
注冊ui截面圖
檢測填入信息合法性
注冊成功告誡
注冊失敗告誡
顯示按鍵實現
4.3車次信息展示界面（與其他信息展示界面基本一致）
相關文章
為您推薦
加載中...