打车软件系统分析与设计方案
摘要??????? 本文是筆者軟件工程與方法課的課程作業，從中國網約車行業的發展歷程及市場現狀出發，立足于當下市場需求，以期設計一款具有市場競爭力的打車軟件。本文首先對打車軟件進行需求分析，然后采用SA方法及DFD描述工具進行系統建模，最后給出相應的設計方案。文章中的打車軟件系統架構圖、系統部署圖、功能架構圖、數據流圖、E-R圖均發布在ProcessOn模板社區，歡迎有需要的同學克隆使用！
關鍵詞：打車軟件；系統分析；設計方案；SA；DFD
1 引言
隨著移動互聯網的發展，各行各業紛紛進行升級轉型。在傳統出租車行業，由于司機繞路、拒載等行為普遍存在，“打車難”、“打車貴”等問題層出不窮。因此，針對這些痛點，打車軟件應運而生。打車軟件，又稱網約車平臺，是指以互聯網技術為依托構建的服務平臺，通過接入符合條件的車輛和駕駛員，整合供需信息，提供非巡游的預約出租汽車服務[1]。
本文的主要工作是完成打車軟件的分析與設計。為設計一款具有市場競爭力的打車軟件，有必要了解當前的市場環境，因此本文首先回顧中國網約車行業的發展歷程，并對網約車市場現狀加以分析。
1.1 中國網約車行業發展歷程
圖 1 中國網約車行業發展歷程[2]
根據易觀的《2019中國網約車市場分析報告》[2]，中國網約車行業的發展大致分為四個階段：探索期（2010-2015）、市場啟動期（2015-2016）、高速發展期（2017-2024）以及應用成熟期（2025-），如圖 1所示。
在探索期，網約車平臺逐漸興起：2010年，易到用車上線；2012年，滴滴打車和快的打車上線；2014年，Uber進入中國，同年，嘀嗒拼車成立；2015年，神州租車推出神州專車業務。
2015-2016兩年間，網約車行業進入競爭激烈的市場啟動期。在這一階段，發生了兩次重大的合并事件：一是滴滴打車和快的打車宣布合并，市場完成初步洗牌；二是滴滴在合并之后又將Uber中國收入囊中，市場進入寡頭化。另一方面，傳統車企和租賃公司也開始向網約車市場進軍，首汽集團的首汽約車、吉利集團的曹操專車于2015年先后上線。
2016年7月，《網絡預約出租汽車經營服務管理暫行辦法》頒布，網約車的合法地位得以肯定。此后，網約車行業進入高速發展期。隨著美團打車、高德地圖以及汽車主機廠的紛紛入局，網約車市場的競爭持續加劇。
1.2 中國網約車市場現狀分析
目前，中國移動出行市場規模快速增長，移動出行用戶將近5億人，汽車出行市場容量達3800億元[3]。網約車服務品牌和業務模式大致分為三類：一類是C2C模式的互聯網平臺，如滴滴出行、嘀嗒出行；一類是B2C模式的車企和租賃公司，車企如上汽投資的享道出行、廣汽投資的如祺出行、吉利的曹操出行及三大央企（長安、一汽、東風）投資的T3出行；租賃公司如首汽約車、神州專車等。此外，最近興起的一類是B2B2C模式的互聯網聚合平臺，以高德和美團為代表，又被稱為“平臺之上的平臺”，方便用戶一鍵呼叫多個第三方平臺的網約車服務。
整體而言，當前的中國網約車市場呈現“一超多強”的競爭格局。滴滴出行占據大部分市場份額，截至2018年12月31日，滴滴出行app安裝滲透率達14.71%，是位列第二的神州專車的10倍以上[4]。滴滴的商業模式屬于“純平臺”模式，這種模式輕量化運營、用戶和數據變現前景可期，但具有較高的進入壁壘。而且由于政府對平臺的監管趨嚴、合規壓力大，運力短缺問題短期內將持續困擾“純平臺”企業[5]。在這種前有圍堵（滴滴）后有追兵（合規政策）的局勢下，若無顛覆性的技術和極端的政治因素出現，“純平臺”模式很難再出現有威脅的新企業。
相較“純平臺”模式，“平臺+運力”模式尚有機會進入網約車市場分一杯羹。“平臺+運力”的網約車公司背靠具有區域優勢的租賃公司、整車廠等，受到當地政府的支持，合規化程度較高，投入相對較少，能夠在盈利性和運力保障間尋求平衡。
另外，從長期來看，網約車市場整體需求將持續高漲。一是隨著疫情的好轉，企業相繼復工，出行市場逐漸復蘇，網約車市場用戶規模將會恢復性增長[6]；二是隨著城鎮化水平提升，經濟持續發展，基礎設施持續完善，中國未來城鎮居民出行需求將持續增長；三是由于私家車的限購及征收擁堵稅，隨著移動共享出行的日益成熟，共享出行將受到更多消費者的青睞。
因此，在需求旺盛且有待開墾的二線城市，“平臺+運力”模式的網約車企業仍具有一定的發展空間。下文將以這樣的企業為業務方，完成打車軟件的系統分析與方案設計。
2 打車軟件系統分析
本節將從需求分析、系統模型兩方面對打車軟件進行系統分析。
2.1 需求分析
需求分析主要可分為業務需求、用戶需求、功能性需求、以及非功能性需求四方面。
2.1.1 業務需求
打車軟件的業務需求是：為乘客提供便捷、舒適、安全的出行服務，為司機提供公平、透明、可靠的接單途徑，從而提高乘客用戶與司機用戶的留存率，通過合作提點、推介傭金、廣告植入、廣告推送、積分換購[7]等方式，實現盈利創收的目的。
2.1.2 用戶需求
打車軟件的主要服務對象是乘客、司機兩種角色，不同的角色對系統的需求是不同的。下面分別對這兩種角色的用戶需求加以分析。
2.1.2.1 乘客用戶需求
打車難、安全焦慮[8]、體驗差等問題仍是網約車及出租車服務面臨的主要問題。雖然相比于傳統的揚招打車，網約車在一定程度上解決了一些問題，但對于問題的最終解決仍有很長的路要走。不久前J.D. Power發布的中國網約車服務質量研究[3]顯示，網約車行業整體PP100（每百用戶抱怨數）偏高，行業平均PP100高達575，即每個用戶平均抱怨5.75個問題。用戶抱怨主要集中在平臺效率方面，叫車過程中的PP100高達166。根據統計數據，“守時”和“高效”對于網約車平臺用戶留存至關重要：如果接單響應時間超過5分鐘，41%的乘客用戶會選擇取消訂單或更換平臺叫車；若接單司機與乘客的距離超過10分鐘路程，50%的乘客用戶會選擇取消該訂單。此外，地圖相關問題也用戶抱怨較多。
上述研究通過對不同品牌和區域網約車用戶進行訪談和調研，重點考察了乘客用戶在打車過程的6大環節（叫車過程、上車過程、乘坐體驗、下車過程、支付和管理以及安全體驗）遇到的問題，能夠較為全面地反映乘客用戶需求。基于此，現將打車軟件的乘客用戶需求總結如表 1：
表 1 打車軟件的乘客用戶需求
| 序號 | 用戶故事 | 需求描述 | 優先級 |
| 1 | 公司或住所位置偏僻，不好打車。 | 系統將用戶的打車信息推送給一定數量的司機，增加用戶成功打到車的機會；提供預約打車功能，使司機提前明確接送任務，保證乘客能打上車。 | P0 |
| 2 | 雨雪天氣或早晚高峰，擔心出門攔不到車，耽誤行程。 | 系統提供加價功能，激勵司機接單，增大司機與乘客相互選擇的空間；確實受天氣或交通等客觀因素限制時，系統提供其他出行方式的建議和參考。 | P0 |
| 3 | 線下打車不劃算。 | 系統提供順風車、拼車功能，設立優惠券、鼓勵金、積分減免等活動。 | P1 |
| 4 | 出租車車型舒適度不夠。 | 系統提供專車打車功能。 | P2 |
| 5 | 攜帶寵物出行。 | 系統提供攜寵打車功能。 | P2 |
| 6 | 攜帶較多貨物出行。 | 系統提供同城送貨、城際送貨功能。 | P2 |
| 7 | 老弱病殘孕人士出行有特殊需求。 | 系統提供愛心打車、無障礙打車功能。 | P2 |
| 8 | 加班到深夜，去偏遠地區，擔心打車不安全。 | 系統提供證照信息公示、一鍵報警功能，保障乘車安全，增加乘客安全感。 | P0 |
| 9 | 去外地出差或旅游，不熟悉路線，擔心司機繞遠，費用高。 | 系統提供高精度的地圖導航，提供即時計費、評價反饋功能，建立誠信機制。 | P0 |
| 10 | 平臺派單時間過長，預計接單時間不準，實際等待時間比預計接單時間長很多，甚至沒有司機接單。 | 系統提供更完善的時間預測算法和司機派單算法；在叫不到車等待時，向乘客顯示等待時間、等待人次、排位順序信息；若超出平臺規定最長派單時間，提供合理的減免優惠。 | P0 |
| 11 | 看到附近有空車打不到，接單司機距離太遠，接單接駕時間長。 | 系統提供更完善的司機派單算法，降低“近單遠接”的概率；做到車輛狀態信息透明化，明確地向乘客展示車輛處于空駛或是已接單狀態。 | P0 |
| 12 | 聯系接單司機浪費時間：司機接單后不主動聯系，只有車輛到達地點后找不到人才聯系，甚至找不到人也不聯系，要不在地點等候，要不在周圍繞圈（不方便停車的地方）。 | 系統提供通知功能，在司機接單后自動向用戶發送消息告知接單司機及車輛相關信息。 | P0 |
| 13 | 車輛到達上車點和實際位置有出入，到達上車點時間不準，導航路線不合理，預計到達目的地時間不準，到達目的地位置不準。 | 與高質量的地圖服務第三方合作，提供更精準的地圖服務。 | P0 |
| 14 | 對司機服務或車輛不滿意。 | 系統提供評價反饋功能。 | P0 |
| 15 | 個人物品落在車內。 | 通過系統的對話功能聯系行程司機。 | P0 |
2.1.2.2 司機用戶需求
打車軟件的司機用戶需求與乘客用戶需求之間存在關聯，現將司機用戶需求總結如表 2：
表 2 打車軟件的司機用戶需求
| 序號 | 用戶故事 | 需求描述 | 優先級 |
| 1 | 不愿意去偏遠地區接單：路程遠，時間長，而且途中接不到其他單。 | 系統提供加價功能，激勵司機接單；提供預約打車功能，使司機提前明確接送任務。 | P0 |
| 2 | 深夜接單前往偏遠地區，擔心不安全。 | 系統提供一鍵報警功能，保障司機安全。 | P0 |
| 3 | 看見附近有乘客想打車，但接不到單；系統分配的乘客距離太遠，接單中途被取消訂單。 | 系統提供更完善的派單算法，降低“近單遠接”的概率。 | P0 |
| 4 | 特殊原因暫時不方便接單（如手機即將沒電）。 | 系統提供拒單功能，并向乘客發送拒單原因，便于司乘之間的雙向選擇。 | P0 |
| 5 | 接單到地點找不到乘客。 | 系統提供對話功能，方便聯系乘客。 | P0 |
| 6 | 對乘客行為或平臺不滿意。 | 系統提供評價反饋功能。 | P0 |
2.1.3 功能性需求
基于上述用戶需求，本節將打車軟件的功能性需求分配至乘客端與司機端。
2.1.3.1 乘客端功能性需求
乘客端主要包括如下功能性需求：
（1）注冊登錄：乘客使用打車軟件進行打車時需要處于登錄狀態，新用戶需要進行注冊，可以選擇使用手機號碼與驗證碼進行注冊，或者使用微信、QQ等第三方賬號授權登錄。
（2）多樣化打車模式：乘客可以選擇即時打車或預約打車，其中即時打車的打車模式有快車、專車、順風車和拼車；預約打車的打車模式有快車、專車、拼車和個性化打車。多樣化的打車模式滿足更廣大用戶群體的需求。
（3）開銷預算：乘客提交打車請求后，系統會根據乘客的出發地和目的地，估算出需要花費的時間及費用，方便司機與乘客。
（4）空車搜索：乘客可以查看附近車輛狀態（空駛/已接單），方便乘客自選車輛打車。
（5）訂單管理：乘客可以查看歷史訂單。在司機接單后，乘客可以查看當前訂單詳情，了解接單司機的相關信息，包括司機的電話號碼，車牌號碼、車輛型號、司機評價、司機實時位置等。在行程開始前，乘客可以取消訂單。
（6）消息管理：乘客可以接收系統通知及司機消息，可以向司機發送消息進行聯系，并且可以查看歷史對話記錄。
（7）即時計費：在乘客上車后計費開始，乘客可以實時查看當前行車路線導航、里程、時間及費用。
（8）一鍵報警：如若遇到危險，乘客可以通過一鍵報警向第三方安全中心求救。
（9）支付：到達目的地后，乘客可以選擇支付寶、微信等第三方支付方式進行支付，同時可以選擇使用優惠券、會員積分等獲得減免。
（10）評價：支付完成后，乘客可以對司機的服務進行評價。
上述需求總結如圖 2：
圖 2 乘客端功能性需求
2.1.3.2 司機端功能性需求
司機端主要包括如下功能性需求：
（1）注冊登錄：司機在使用打車軟件時需要處于登錄狀態，新用戶需要注冊，向系統提交手機號、駕駛證號、本人與車輛合照等信息，審核通過后才能進行接單。
（2）訂單管理：司機在收到系統推送的訂單時，可以選擇接單或拒單。司機選擇接單后可以查看當前訂單詳情，確定乘客的上車地點。另外，司機可以查看歷史訂單信息，方便對工作量的評估。
（3）乘客搜索：司機可以查看附近請求打車的乘客狀態（未上車/已上車），方便司機自找乘客。
（4）行車導航：司機可以根據行車導航出發去接乘客，并且可以通過導航確定從乘客出發地到目的地的合適路線。
（5）消息管理：司機可以接收系統通知，與乘客對話溝通，并可以查看歷史對話記錄。
（6）一鍵報警：如若遇到危險，司機可以通過一鍵報警向第三方安全中心求救。
（7）評價：訂單結束后，司機可以對乘客進行評價。
（8）收入查詢：司機可以查看載客所收到的報酬，通過綁定銀行卡提現。
上述需求總結如圖 3：
圖 3 司機端功能性需求
2.1.4 非功能性需求
如表 3所示，打車軟件不僅要實現用戶的基本需求，而且在性能、安全性、軟件質量屬性等方面有一定的限制要求。
表 3 打車軟件的非功能性需求
| 類型 | 需求描述 |
| 性能需求 | 業務量：系統滿足多用戶同時工作，保障同時在線用戶數500W人，并發操作100W人的使用要求。 |
| 響應時間：在95％的情況下，一般時段響應時間不超過1.5秒，高峰時段不超過4秒。 | |
| 精度：地圖定位精度誤差不超過80米。 | |
| 系統容量：滿足未來5年業務數據擴展要求。 | |
| 資源使用率：CPU占用率<=50%，內存占用率<=50%。 | |
| 安全性需求 | 嚴格權限訪問控制，用戶在經過身份認證后，只能訪問其權限范圍內的數據，只能進行其權限范圍內的操作。 |
| 提供運行日志管理及安全審計功能，可追蹤系統的歷史使用情況。 | |
| 網絡傳遞數據應經過加密。需要保證數據在采集、傳輸和處理過程中不被偷窺、竊取、篡改。 | |
| 能經受來自互聯網的一般性惡意攻擊，如病毒（包括木馬）攻擊、口令猜測攻擊、黑客入侵等，至少90%的攻擊需要在10秒內檢測到。 | |
| 軟件質量屬性 | 易用性：打車軟件面向用戶群體廣泛，為方便老人使用，要求操作簡單，界面美觀，用戶容易上手，體驗良好。 |
| 可靠性：連續運行一周不得出現閃退或程序未響應的情況。 | |
| 健壯性：對于運行過程中出現的各種異常情況，如：人為操作錯誤、輸入非法數據、硬件設備失敗等，系統能正確地處理回避。 | |
| 效率性：盡可能優化通信協議，減少網速對系統的影響。 | |
| 兼容性：可運行于安卓系統2.3.0及以上的各個品牌的智能手機上。 | |
| 易集成性：要求代碼精簡、集成度高，易于嵌入美團、高德等互聯網聚合平臺，有利于后期的發展。 | |
| 可擴展性：軟件采用模塊化設計，接口要標準化，以適應未來功能擴展的需求。 | |
| 可測試性：軟件開發過程中使用回歸測試，交付必須通過100%覆蓋的單元測試。 | |
| 可維護性：一個模塊的最大圈復雜度不超過15。 | |
| 其他需求 | 軟件需按照公司整體風格進行UI調整、色調調整等。 |
| 軟件需遵守最新法律法規，根據所在地區規定提供相應的服務。 |
2.2 系統模型
根據上述需求分析，本節采用結構化分析方法（SA, Structure Analysis）中的數據流圖（DFD, Data Flow Diagram）定義系統模型。
打車軟件的頂層數據流圖如圖 4，系統以乘客、司機、第三方地圖、第三方支付、以及第三方安全中心為邊界。
圖 4 打車軟件頂層數據流圖
圖 5 打車軟件一層數據流圖
圖 5為打車軟件的一層數據流圖，將系統拆分為注冊登錄、搜索、打車、定位導航、開銷預算、派單、訂單管理、即時計費、消息管理、評價、報警、電子支付及收入查詢環節。由于該數據流圖線條繁雜，在此不再給出其細化后的二層數據流圖及數據文件，下文的功能設計（3.1節）與數據設計小節（3.2節）將對打車軟件的功能與數據做進一步設計說明。
3 打車軟件設計方案
本節將從功能設計、數據設計、系統架構、系統部署、關鍵技術五方面介紹打車軟件的設計方案。
3.1 功能設計
對比乘客端與司機端的功能性需求發現：乘客端與司機端的很多功能是相似的、甚至相同的。因此，相似或相同的功能可并入一個模塊處理。如圖 6，最終整個打車軟件系統可分為個人信息、打車、定位、訂單管理、消息管理五個模塊。
圖 6 打車軟件功能架構
其中，個人信息、定位、訂單管理、消息管理模塊是乘客端與司機端都擁有的，打車模塊是屬于乘客端的。各功能點已在2.1.3節進行過描述，在此不再贅述。
3.2 數據設計
本節將從數據庫概念設計、數據庫邏輯設計、數據庫物理設計三方面對系統數據進行設計。
3.2.1 數據庫概念設計
打車軟件系統的E-R圖如圖 7所示，可以看到：一個乘客可以預定和支付多個訂單，一個司機也可以接收多個訂單；但一個司機只能駕駛一輛網約車。另外，司機與乘客之間還存在搭乘、對話及評價關系。
圖 7 打車軟件系統E-R圖
3.2.2 數據庫邏輯設計
根據系統模型，本文為打車軟件系統設計了8個數據表，包括乘客信息表、司機信息表、乘客位置表、司機位置表、訂單記錄表、消息記錄表、乘客評價記錄表、司機評價記錄表。各數據表的設計結構如下：
- 乘客信息表（passenger）：記錄乘客端用戶的基本信息，乘客用戶注冊時添加的用戶名、密碼、姓名、性別、手機號等基本信息都會存入該表中。該表的主鍵為乘客編號。
- 司機信息表（driver）：記錄司機端用戶的基本信息，司機端用戶注冊時添加的用戶名、密碼、姓名、性別、手機號、身份證號、駕駛證號等基本信息都會存入該表中。該表的主鍵為司機編號。
- 乘客位置表（passenger_location）：記錄當前乘客的位置信息，包括位置編號、經度、緯度、當前時刻、乘客編號、乘客狀態。該表主鍵為位置編號。
- 司機位置表（driver_location）：記錄當前司機的位置信息，包括位置編號、經度、緯度、當前時刻、司機編號、司機狀態。該表主鍵為位置編號。
- 訂單記錄表（order）：記錄每次打車訂單的基本信息，包括訂單編號、乘客編號、司機編號、起點、終點、打車時間、上車時間等基本信息。該表主鍵為訂單編號。
- 消息記錄表（message）：記錄乘客與司機的對話信息，包括消息編號、訂單編號、消息發送者編號、消息接收者編號、消息發送時間。該表主鍵為消息編號。
- 乘客評價表（passenger_review）：記錄司機給乘客的評價信息，包括評價編號、乘客編號、訂單編號、評價等級、評價內容、評價人編號、評價時間。該表主鍵為評價編號。
- 司機評價表（driver_review）：記錄乘客給司機的評價信息，包括評價編號、司機編號、訂單編號、評價等級、評價內容、評價人編號、評價時間。該表主鍵為評價編號。
3.2.3 數據庫物理設計
數據庫物理設計的工作是具體化設計數據字段名、數據類型及相關約束。上述數據表的物理設計如下：
表 4 乘客信息表（passenger）-與個人信息模塊相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | passengerId | INT(20) | 乘客編號PK |
| 2 | usr | VARCHAR(50) | 用戶名 |
| 3 | psw | VARCHAR(50) | 密碼 |
| 4 | name | VARCHAR(50) | 姓名 |
| 5 | sex | VARCHAR(3) | 性別 |
| 6 | idno | VARCHAR(20) | 身份證號 |
| 7 | tel | VARCHAR(11) | 手機號 |
表 5 司機信息表（driver）-與個人信息模塊相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | driverId | INT(20) | 司機編號PK |
| 2 | usr | VARCHAR(50) | 用戶名 |
| 3 | psw | VARCHAR(50) | 密碼 |
| 4 | name | VARCHAR(50) | 姓名 |
| 5 | sex | VARCHAR(3) | 性別 |
| 6 | idno | VARCHAR(20) | 身份證號 |
| 7 | tel | VARCHAR(11) | 手機號 |
| 8 | license | VARCHAR(20) | 駕駛證號 |
| 9 | carno | VARCHAR(20) | 車牌號 |
| 10 | cartype | VARCHAR(20) | 車型 |
表 6 乘客位置表（passenger_location）-與定位模塊相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | locId | INT(20) | 位置編號PK |
| 2 | longitude | DOUBLE | 經度 |
| 3 | latitude | DOUBLE | 緯度 |
| 4 | time | TIME | 當前時刻 |
| 5 | passengerId | INT(20) | 乘客編號 |
| 6 | status | INT(2) | 乘客狀態 |
表 7 司機位置表（driver_location）-與定位模塊相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | locId | INT(20) | 位置編號PK |
| 2 | longitude | DOUBLE | 經度 |
| 3 | latitude | DOUBLE | 緯度 |
| 4 | time | TIME | 當前時刻 |
| 5 | driverId | INT(20) | 司機編號 |
| 6 | status | INT(2) | 司機狀態 |
表 8 訂單記錄表（order）-與訂單管理模塊相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | orderId | INT(20) | 訂單編號PK |
| 2 | passengerId | INT(20) | 乘客編號 |
| 3 | driverId | INT(20) | 司機編號 |
| 4 | startloc | VARCHAR(50) | 起點 |
| 5 | endloc | VARCHAR(50) | 終點 |
| 6 | ordertime | DATETIME | 下單時間 |
| 7 | starttime | DATETIME | 上車時間 |
| 8 | endtime | DATETIME | 到達時間 |
| 9 | mileage | DOUBLE | 里程 |
| 10 | cost | DOUBLE | 費用 |
| 11 | status | INT(2) | 訂單狀態 |
表 9 消息記錄表（message）-與消息管理模塊相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | messageId | INT(20) | 消息編號PK |
| 2 | orderId | INT(20) | 訂單編號 |
| 3 | senderId | INT(20) | 消息發送者編號 |
| 4 | receiverId | INT(20) | 消息接收者編號 |
| 5 | time | DATETIME | 消息發送時間 |
表 10 乘客評價表（passenger_review）-與訂單管理模塊的評價功能相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | reviewId | INT(20) | 評價編號PK |
| 2 | passengerId | INT(20) | 乘客編號 |
| 3 | orderId | INT(20) | 訂單編號 |
| 4 | rating | INT(2) | 評價等級 |
| 5 | content | TEXT | 評價內容 |
| 6 | reviewerId | INT(20) | 評價人編號 |
| 7 | time | DATETIME | 評價時間 |
表 11 司機評價表（driver_review）-與訂單管理模塊的評價功能相關
| 編號 | 字段 | 數據類型 | 備注 |
| 1 | reviewId | INT(20) | 評價編號PK |
| 2 | driverId | INT(20) | 司機編號 |
| 3 | orderId | INT(20) | 訂單編號 |
| 4 | rating | INT(2) | 評價等級 |
| 5 | content | TEXT | 評價內容 |
| 6 | reviewerId | INT(20) | 評價人編號 |
| 7 | time | DATETIME | 評價時間 |
3.3 系統架構
系統設計采用MVC（Model View Controller）框架模式，這種框架模式以數據、界面顯示、業務邏輯分離的方法組織代碼，在改良和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯，使代碼具有較好的可擴展性、可復用性、可維護性及靈活性。系統架構如圖 8所示，分為三層：前端表現層、業務邏輯層、物理數據層。
圖?8 打車軟件系統架構
其中，前端表現層主要接收用戶請求，并為用戶呈現信息；業務邏輯層調用模型完成相應的業務，與數據庫聯動處理增刪改查操作；物理數據層用于存儲業務相關數據。
3.4 系統部署
打車軟件基于C/S模型，其乘客端和司機端屬于移動客戶端，客戶端之間通過網絡進行通信，服務器端使用負載均衡和集群化的方式來應對高并發的業務需求。系統部署如圖 9。
圖 9 打車軟件系統部署
3.5 關鍵技術
實現打車軟件的關鍵技術如下表 12，包括操作系統、數據庫、移動通信技術等：
表 12 打車軟件的關鍵技術
| 技術類型? | 技術點 | 使用原因 |
| 操作系統 | 客戶端為Andriod/iOS，服務器端為Linux | 打車軟件客戶端主要運行在智能手機終端，主流操作系統為Andriod與iOS；服務器端選用Linux，是因其具有穩定、安全、易用、費用低的優點。 |
| 數據庫 | MySQL、Redis | MySQL用于持久化存儲，Redis用于緩存。 |
| 移動通信技術 | 流量控制、負載均衡、實時通信 | 應對高并發、低延遲的業務需求。 |
| 數據交換技術 | json、壓縮 | json常用于數據傳輸，為提升傳輸效率，使用壓縮技術。 |
| 業務流程 | 派單算法、開銷預測算法、計費算法 | 打車軟件需要專用算法完成業務流程，派單、開銷預測、計費等環節對用戶體驗至關重要。 |
| 地圖和定位 | 空間索引、空間計算 | 空車搜索、乘客搜索等功能需要對空間數據進行高效地查詢。 |
| 隱私保護技術 | 基于位置的K匿名、差分隱私 | 用戶的位置、運行軌跡等信息屬于個人敏感信息，需要脫敏處理。 |
| 安全技術 | 加密算法 | 用戶密碼等數據不得以明文形式進行傳輸。 |
4 總結
本文主要對打車軟件進行系統分析和設計，首先使用SA方法及DFD工具進行系統分析，然后使用MVC框架模式進行系統設計，最后指明了打車軟件的系統部署及關鍵技術。
參考文獻
??【1】網約車_百度百科[EB/OL]. https://baike.baidu.com/item/%E7%BD%91%E7%BA%A6%E8%BD%A6. 2020年7月20日訪問.
【2】易觀. 2019中國網約車市場分析報告. 2019年7月.
【3】J.D. Power. 2020中國網約車服務質量研究報告. 2020年3月.
【4】極光大數據. 2019年1月網約車行業研究報告. 2019年1月.
【5】德勤咨詢. 十字路口的網約車. 2019年1月.
【6】CNNIC. 第45次中國互聯網絡發展狀況統計報告. 2020年4月.
【7】牛偉娜, 馬倩瑤. 我國打車軟件盈利模式探討[J]. 合作經濟與科技, 2016(19):110-111.
【8】極光. 2019年網約車出行安全用戶信心研究報告. 2019年12月.
總結
以上是生活随笔為你收集整理的打车软件系统分析与设计方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： UG NX 12 坐标系的操作
- 下一篇： UG NX 12 同步建模：删除面