1.前言
本文將基於一個火車售票系統，進行用例建模，業務領域建模以及數據建模，最終形成概念原型。
2.需求概述
本系統包含兩個子系統，分為用戶系統與后台管理系統。
1. 用戶系統的主要功能
- 用戶注冊
- 用戶信息維護
- 查找車票
- 購買車票
- 改簽及退票
2. 后台管理系統的主要功能
3.用例設計
本系統分為兩個角色：普通用戶和管理者
普通用戶用例圖：
管理者用例圖：
4.業務類圖
在進行UML建模前，我們需要先對業務領域進行詳細分析和描述，並對業務相關知識概念進行分類，最后使用UML進行圖形化展示。
1. 建模步驟
1）第一步，收集應用業務領域的信息。聚焦在功能需求層面，也考慮其他類型的需求和資料。
2）第二步，頭腦風暴。列出重要的應用業務領域概念，給出這些概念的屬性，以及這些概念之間的關系
3）第三步，給這些應用業務領域概念分類。分別列出哪些是類、哪些屬性和屬性值、以及列出類之間的繼承關系、聚合關系和關聯關系。
4）第四步，將結果用 UML 類圖畫出來。
2. 業務過程說明
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） 失敗：失敗原因
3. UML建模
根據以上業務需求描述，並結合面向對象的思想，抽象出類、屬性、方法，同時確定概念之間的關系，構建UML類圖：
5.數據模型設計
1. 采用關系數據庫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 |
屬性取值 |
2. 關於設計思路的補充說明
（1） 對於關系型數據庫，一般情況下遵循其范式原則，但范式並非越高越好。為了提升查找性能，可以有針對性性地進行反范式設計，例如當查詢頻率遠高於修改頻率時，或數據基本不改動時，可適當增加冗余來提高查詢效率。此時則需要注意冗余字段的一致性問題。本系統中，在用戶表中增加authority冗余字段，從而減少多表查詢帶來的性能損耗。
（2）對於實體間一對多的設計，可分為以下情況討論：
- 一對多中的多並非單獨實體，且規模較少，如各表中的type類型字段：直接內嵌在實體中，不再單獨建立實體表。
- 一對多中的多需要單獨的實體，且規模較多，如列車表中的車廂，車廂表中的座位等字段：單獨建實體表，並通過外鍵進行關聯。（實際開發中在業務層保證）
- 一對多中的多規模非常龐大時，如用戶表中的角色：可將一對多中的‘一’內嵌入‘多’的實體中，本系統由於考慮到后續開發的擴展性問題，並未采用。
（3）一些通用開發經驗：
- 實體表的設計中，優先考慮使用內嵌。
- 一個字段無法描述，需要使用實體時，應該單獨設計實體表
- 在關系數據庫的設計中，考慮范式的同時，應結合具體業務進行必要的反范式設計
- 對於是否進行冗余，判斷的主要依據是讀寫頻率
- 多表關聯查詢時，如果效果不佳，考慮增加索引進行優化
6.概念原型
1. 概念原型的定義方式
概念原型是一種虛擬的、理想化的軟件產品形式。其定義用以下公式描述:
概念原型 = 用例 + 數據模型。 其中，用例及數據模型在本文中已詳細闡述。
2. 工作過程舉例
- 用戶注冊：用戶填寫注冊信息【用戶數據模型：賬號，密碼，姓名，性別，電話號碼，證件號碼...】，系統進行校驗，並返回相應信息。
- 查票：用戶輸入或選擇篩選條件，系統返回車票信息【車票數據模型：車次號，座位號，起點站，終點站，發車時間，到達時間，票價...】
7.總結
本文參考了軟件工程的相關知識，並結合工程實踐項目，對軟件過程中的需求分析和概念原型設計做了細致闡述。在此過程中，我對系統本身業務的理解也更為深刻，也將有利於后續系統的開發。文中涉及的其它細節，我將會在系統開發的同時進行補充和完善。
