1.架構設計
1. 系統架構選型
從軟件架構角度，本系統采用了MVC分層的設計思想，各層級只需要關注本身的設計，而不需要關注其他層級的內部細節，層與層之間定義了良好的交互方式。具體而言，本系統可以分為三個水平層，分別是展示層，業務服務層和數據庫層；系統總體結構如下圖所示。
2. 軟件架構風格
本系統采用瀏覽器-服務模式（B/S模式），該模式是Web興起后的一種網絡結構模式。相比較傳統的C/S模式，B/S結構的重要特征就是分布性強、開發簡單、共享性強、總體擁有費用低。這種模式統一了客戶端，將系統功能實現的核心部分集中到服務器上，簡化了系統的開發、維護和使用。
BS架構優勢總結如下：
● 分布性強，客戶端零維護。只需有網絡、瀏覽器，能夠隨時隨地實行查詢、瀏覽等業務處理。
● 業務擴展簡單便利，通過添加網頁就可以添加服務器功能。
● 維護簡單便利，只須要更改網頁，就可以完成全部用戶的同步更新。
● 開發簡單，共享性強。
2. 業務概念原型
1. 用例設計
- 用戶主要功能：用戶注冊、用戶信息維護、查找車票、購買車票、改簽及退票
- 后台管理員主要功能：列車信息維護、站點信息維護、車次設置
2. UML類圖設計
根據業務需求描述，結合面向對象的思想，抽象出類、屬性、方法，同時確定概念之間的關系，構建UML類圖：
3. 數據庫設計
采用關系數據庫mysql進行設計
（1）用戶表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| userId | int | 主鍵 |
| account | varchar | 賬號 |
| password | varchar | 密碼 |
| name | varchar | 姓名 |
| sex | varchar | 性別 |
| phonenum | number | 電話號碼 |
| certificate_type | varchar | 證件類型 |
| certificate_num | number | 證件號碼 |
| authority | varchar | 權限 |
| info | varchar | 其它信息 |
（2）角色表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| roleId | int | 主鍵 |
| role_type | varchar | 角色類型 |
| authority | varchar | 權限 |
| descr | varchar | 描述 |
（3） 用戶角色關聯表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| urId | int | 主鍵 |
| userId | int | 用戶主鍵【外鍵】 |
| roleId | int | 角色主鍵【外鍵】 |
（4） 車次表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| trainSequenceId | int | 主鍵 |
| trainNum | number | 車次號 |
| trainId | int | 列車號 |
| start_station | varchar | 起點站 |
| end_station | varchar | 終點站 |
| launch_time | datetime | 啟動時間 |
（5） 列車表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| trainId | int | 主鍵 |
| trainName | varchar | 列車名稱【外鍵】 |
| type | varchar | 列車類型 |
| carriage_num | int | 車廂數 |
| status | int | 狀態 |
（6） 車廂表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| carriageId | int | 主鍵 |
| trainId | int | 列車主鍵【外鍵】 |
| carriage_number | int | 車廂號 |
| carriage_type | int | 車廂類型 |
| price_coef | int | 價格系數 |
（7） 座位表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| seatId | int | 座位主鍵 |
| carriageId | int | 車廂主鍵【外鍵】 |
| trainId | int | 列車主鍵【外鍵】 |
| seat_number | int | 座位號 |
| bitmap | int | 座位站點狀態位圖 |
（8） 站點表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| stationId | int | 站點主鍵 |
| name | varchar | 站點名稱 |
| descr | varchar | 站點級別 |
（9） 車次站點表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| train_sta_Id | int | 車次站點主鍵 |
| trainSequenceId | int | 車次主鍵【外鍵】 |
| station_sequence | int | 站點序列 |
| arrive_time | datetime | 到達時間 |
| lanch_time | datetime | 啟動時間 |
（10） 訂單表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| orderId | int | 訂單主鍵 |
| userId | int | 用戶主鍵【外鍵】 |
| seatId | int | 座位主鍵【外鍵】 |
| order_time | datetime | 時間 |
| status | varchar | 訂單狀態 |
| descr | varchar | 訂單描述 |
（11） 字典表
| 字段名稱 | 字段類型 | 字段描述 |
|---|---|---|
| dictionaryId | int | 字典表主鍵 |
| attributes | varchar | 屬性名稱 |
| value | varchar | 屬性取值 |
4. 分解視圖
針對業務模塊進行分解
5. 實現視圖
項目的目錄結構設計
本項目采用MVC分層架構，其中，主流的目錄結構設計是按照controller、service、dao層來進行分包。然而，考慮到本項目業務模塊較少，且Go web中忌諱包名后綴重復（例如import service.userService），我們根據業務模塊進行分包，如圖所示：
6. 執行視圖
時序圖：以用戶購票業務為例
7. 部署視圖
部署圖描述的是系統運行時的結構，展示了硬件的配置及其軟件如何部署到網絡結構中。
一個系統模型只有一個部署圖，部署圖通常用來幫助理解分布式系統。部署視圖有助於設計人員分析一個設計的質量屬性，比如軟件處理網絡高並發的能力、軟件對處理器的計算需求等。
8. API接口
1. 用戶注冊：
- 功能描述：用戶注冊個人賬號
- 處理流程及要點：用戶填寫個人基本信息並提交，系統驗證用戶信息合法性，如果不合法，則返回相應的錯誤提示信息；否則提示注冊成功，向表中插入數據
- 輸入：賬號，密碼，性別，年齡，證件類型，證件號碼
- 輸出：（1）成功：注冊成功 （2） 失敗：失敗原因
2. 用戶登錄
- 功能描述：用戶登錄火車售票平台
- 處理流程及要點：用戶輸入賬號密碼並提交，系統進行驗證，如果通過則進入主頁面；否則登錄失敗，並返回相應信息
- 輸入：賬號名，密碼
- 輸出：（1）成功：登錄成功 （2） 失敗：失敗原因
3. 查票
- 功能描述：普通用戶查詢車票
- 處理流程及要點：用戶輸入篩選信息，系統返回滿足條件的查找結果
- 輸入：起點站，終點站，（可選項：時間，座次，車次）
- 輸出：（1）成功：返回查找結果 （2） 失敗：返回失敗原因
4. 購票
- 功能描述：普通用戶購買車票
- 處理流程及要點：用戶輸入篩選信息進行查票，選擇車票購買，系統判斷出票條件進行出票，成功出票則生成訂單信息
- 輸入：車次，座位號
- 輸出：（1）成功：車票信息，包括車次，買票人信息，始發站，終點站，時間，座位號 （2） 失敗：失敗原因
5. 改簽、退票
- 功能描述：普通用戶改簽車票或退票
- 處理流程及要點：用戶選擇要改簽/退票的車票，系統重置該車票的信息及狀態
- 輸入：車次，座位號，若改簽則還需輸入改簽時間
- 輸出：（1）成功：返回車票信息或狀態 （2） 失敗：返回失敗原因
6. 站點信息維護
- 功能描述：管理員用戶維護站點信息
- 處理流程及要點：管理員用戶維護站點表，主要包括增刪改查等操作
- 輸入：增刪改查相應參數
- 輸出：（1）成功：成功信息 （2） 失敗：失敗原因
7. 列車信息維護
- 功能描述：管理員用戶維護列車信息
- 處理流程及要點：管理員用戶維護列車表、車廂表、座位表，主要包括增刪改查等操作
- 輸入：增刪改查相應參數
- 輸出：（1）成功：成功信息 （2） 失敗：失敗原因
8. 車次設置
- 功能描述：管理員用戶添加車次信息
- 處理流程及要點：管理員用戶輸入車次信息，系統進行判斷和驗證，並執行對應業務邏輯
- 輸入：列車ID，始末站點，中途站點，各站點區間票價，發車日期和時間
- 輸出：（1）成功：該車次信息 （2） 失敗：失敗原因
9. 技術選型
1. 開發技術
- 編程語言：GoLang
- 后端框架：Gin
- 持久化層：Gorm，Mysql
- 緩存層：Redis
- 部署環境：Linux，Docker
2. 設計模式
- 單例模式：數據庫連接池。創建數據庫連接是一個很耗時的操作，也容易對數據庫造成安全隱患。所以，在程序初始化的時候，集中創建多個數據庫連接，並把他們集中管理，供程序使用，可以保證較快的數據庫讀寫速度，還更加安全可靠。
- 管道模式：消息中間件。通過中間件實現業務的解耦，在代碼實現時，我們只需要關注各個階段的實現，最后通過管道方式拼接起來。
- 享元模式：運用共享技術來有效地支持大量細粒度對象的復用，比如線程池。
10. 系統概念原型工作機制
以用戶注冊和查票為例進行說明
- 用戶注冊：用戶填寫注冊信息【用戶數據模型：賬號，密碼，姓名，性別，電話號碼，證件號碼...】，系統進行校驗，並返回相應信息。
- 查票：用戶輸入或選擇篩選條件，系統返回車票信息【車票數據模型：車次號，座位號，起點站，終點站，發車時間，到達時間，票價...】