摘要??????? 本文是筆者軟件工程與方法課的課程作業(yè)，從中國網(wǎng)約車行業(yè)的發(fā)展歷程及市場現(xiàn)狀出發(fā)，立足于當下市場需求，以期設計一款具有市場競爭力的打車軟件。本文首先對打車軟件進行需求分析，然后采用SA方法及DFD描述工具進行系統(tǒng)建模，最后給出相應的設計方案。文章中的打車軟件系統(tǒng)架構圖、系統(tǒng)部署圖、功能架構圖、數(shù)據(jù)流圖、E-R圖均發(fā)布在ProcessOn模板社區(qū)，歡迎有需要的同學克隆使用！

關鍵詞：打車軟件；系統(tǒng)分析；設計方案；SA；DFD

1 引言

隨著移動互聯(lián)網(wǎng)的發(fā)展，各行各業(yè)紛紛進行升級轉型。在傳統(tǒng)出租車行業(yè)，由于司機繞路、拒載等行為普遍存在，“打車難”、“打車貴”等問題層出不窮。因此，針對這些痛點，打車軟件應運而生。打車軟件，又稱網(wǎng)約車平臺，是指以互聯(lián)網(wǎng)技術為依托構建的服務平臺，通過接入符合條件的車輛和駕駛員，整合供需信息，提供非巡游的預約出租汽車服務[1]。

本文的主要工作是完成打車軟件的分析與設計。為設計一款具有市場競爭力的打車軟件，有必要了解當前的市場環(huán)境，因此本文首先回顧中國網(wǎng)約車行業(yè)的發(fā)展歷程，并對網(wǎng)約車市場現(xiàn)狀加以分析。

1.1 中國網(wǎng)約車行業(yè)發(fā)展歷程

圖 1 中國網(wǎng)約車行業(yè)發(fā)展歷程[2]

根據(jù)易觀的《2019中國網(wǎng)約車市場分析報告》[2]，中國網(wǎng)約車行業(yè)的發(fā)展大致分為四個階段：探索期（2010-2015）、市場啟動期（2015-2016）、高速發(fā)展期（2017-2024）以及應用成熟期（2025-），如圖 1所示。

在探索期，網(wǎng)約車平臺逐漸興起：2010年，易到用車上線；2012年，滴滴打車和快的打車上線；2014年，Uber進入中國，同年，嘀嗒拼車成立；2015年，神州租車推出神州專車業(yè)務。

2015-2016兩年間，網(wǎng)約車行業(yè)進入競爭激烈的市場啟動期。在這一階段，發(fā)生了兩次重大的合并事件：一是滴滴打車和快的打車宣布合并，市場完成初步洗牌；二是滴滴在合并之后又將Uber中國收入囊中，市場進入寡頭化。另一方面，傳統(tǒng)車企和租賃公司也開始向網(wǎng)約車市場進軍，首汽集團的首汽約車、吉利集團的曹操專車于2015年先后上線。

2016年7月，《網(wǎng)絡預約出租汽車經營服務管理暫行辦法》頒布，網(wǎng)約車的合法地位得以肯定。此后，網(wǎng)約車行業(yè)進入高速發(fā)展期。隨著美團打車、高德地圖以及汽車主機廠的紛紛入局，網(wǎng)約車市場的競爭持續(xù)加劇。

1.2 中國網(wǎng)約車市場現(xiàn)狀分析

目前，中國移動出行市場規(guī)?？焖僭鲩L，移動出行用戶將近5億人，汽車出行市場容量達3800億元[3]。網(wǎng)約車服務品牌和業(yè)務模式大致分為三類：一類是C2C模式的互聯(lián)網(wǎng)平臺，如滴滴出行、嘀嗒出行；一類是B2C模式的車企和租賃公司，車企如上汽投資的享道出行、廣汽投資的如祺出行、吉利的曹操出行及三大央企（長安、一汽、東風）投資的T3出行；租賃公司如首汽約車、神州專車等。此外，最近興起的一類是B2B2C模式的互聯(lián)網(wǎng)聚合平臺，以高德和美團為代表，又被稱為“平臺之上的平臺”，方便用戶一鍵呼叫多個第三方平臺的網(wǎng)約車服務。

整體而言，當前的中國網(wǎng)約車市場呈現(xiàn)“一超多強”的競爭格局。滴滴出行占據(jù)大部分市場份額，截至2018年12月31日，滴滴出行app安裝滲透率達14.71%，是位列第二的神州專車的10倍以上[4]。滴滴的商業(yè)模式屬于“純平臺”模式，這種模式輕量化運營、用戶和數(shù)據(jù)變現(xiàn)前景可期，但具有較高的進入壁壘。而且由于政府對平臺的監(jiān)管趨嚴、合規(guī)壓力大，運力短缺問題短期內將持續(xù)困擾“純平臺”企業(yè)[5]。在這種前有圍堵（滴滴）后有追兵（合規(guī)政策）的局勢下，若無顛覆性的技術和極端的政治因素出現(xiàn)，“純平臺”模式很難再出現(xiàn)有威脅的新企業(yè)。

相較“純平臺”模式，“平臺+運力”模式尚有機會進入網(wǎng)約車市場分一杯羹。“平臺+運力”的網(wǎng)約車公司背靠具有區(qū)域優(yōu)勢的租賃公司、整車廠等，受到當?shù)卣闹С?#xff0c;合規(guī)化程度較高，投入相對較少，能夠在盈利性和運力保障間尋求平衡。

另外，從長期來看，網(wǎng)約車市場整體需求將持續(xù)高漲。一是隨著疫情的好轉，企業(yè)相繼復工，出行市場逐漸復蘇，網(wǎng)約車市場用戶規(guī)模將會恢復性增長[6]；二是隨著城鎮(zhèn)化水平提升，經濟持續(xù)發(fā)展，基礎設施持續(xù)完善，中國未來城鎮(zhèn)居民出行需求將持續(xù)增長；三是由于私家車的限購及征收擁堵稅，隨著移動共享出行的日益成熟，共享出行將受到更多消費者的青睞。

因此，在需求旺盛且有待開墾的二線城市，“平臺+運力”模式的網(wǎng)約車企業(yè)仍具有一定的發(fā)展空間。下文將以這樣的企業(yè)為業(yè)務方，完成打車軟件的系統(tǒng)分析與方案設計。

2 打車軟件系統(tǒng)分析

本節(jié)將從需求分析、系統(tǒng)模型兩方面對打車軟件進行系統(tǒng)分析。

2.1 需求分析

需求分析主要可分為業(yè)務需求、用戶需求、功能性需求、以及非功能性需求四方面。

2.1.1 業(yè)務需求

打車軟件的業(yè)務需求是：為乘客提供便捷、舒適、安全的出行服務，為司機提供公平、透明、可靠的接單途徑，從而提高乘客用戶與司機用戶的留存率，通過合作提點、推介傭金、廣告植入、廣告推送、積分換購[7]等方式，實現(xiàn)盈利創(chuàng)收的目的。

2.1.2 用戶需求

打車軟件的主要服務對象是乘客、司機兩種角色，不同的角色對系統(tǒng)的需求是不同的。下面分別對這兩種角色的用戶需求加以分析。

2.1.2.1 乘客用戶需求

打車難、安全焦慮[8]、體驗差等問題仍是網(wǎng)約車及出租車服務面臨的主要問題。雖然相比于傳統(tǒng)的揚招打車，網(wǎng)約車在一定程度上解決了一些問題，但對于問題的最終解決仍有很長的路要走。不久前J.D. Power發(fā)布的中國網(wǎng)約車服務質量研究[3]顯示，網(wǎng)約車行業(yè)整體PP100（每百用戶抱怨數(shù)）偏高，行業(yè)平均PP100高達575，即每個用戶平均抱怨5.75個問題。用戶抱怨主要集中在平臺效率方面，叫車過程中的PP100高達166。根據(jù)統(tǒng)計數(shù)據(jù)，“守時”和“高效”對于網(wǎng)約車平臺用戶留存至關重要：如果接單響應時間超過5分鐘，41%的乘客用戶會選擇取消訂單或更換平臺叫車；若接單司機與乘客的距離超過10分鐘路程，50%的乘客用戶會選擇取消該訂單。此外，地圖相關問題也用戶抱怨較多。

上述研究通過對不同品牌和區(qū)域網(wǎng)約車用戶進行訪談和調研，重點考察了乘客用戶在打車過程的6大環(huán)節(jié)（叫車過程、上車過程、乘坐體驗、下車過程、支付和管理以及安全體驗）遇到的問題，能夠較為全面地反映乘客用戶需求。基于此，現(xiàn)將打車軟件的乘客用戶需求總結如表 1：

表 1 打車軟件的乘客用戶需求

序號	用戶故事	需求描述	優(yōu)先級
1	公司或住所位置偏僻，不好打車。	系統(tǒng)將用戶的打車信息推送給一定數(shù)量的司機，增加用戶成功打到車的機會；提供預約打車功能，使司機提前明確接送任務，保證乘客能打上車。	P0
2	雨雪天氣或早晚高峰，擔心出門攔不到車，耽誤行程。	系統(tǒng)提供加價功能，激勵司機接單，增大司機與乘客相互選擇的空間；確實受天氣或交通等客觀因素限制時，系統(tǒng)提供其他出行方式的建議和參考。	P0
3	線下打車不劃算。	系統(tǒng)提供順風車、拼車功能，設立優(yōu)惠券、鼓勵金、積分減免等活動。	P1
4	出租車車型舒適度不夠。	系統(tǒng)提供專車打車功能。	P2
5	攜帶寵物出行。	系統(tǒng)提供攜寵打車功能。	P2
6	攜帶較多貨物出行。	系統(tǒng)提供同城送貨、城際送貨功能。	P2
7	老弱病殘孕人士出行有特殊需求。	系統(tǒng)提供愛心打車、無障礙打車功能。	P2
8	加班到深夜，去偏遠地區(qū)，擔心打車不安全。	系統(tǒng)提供證照信息公示、一鍵報警功能，保障乘車安全，增加乘客安全感。	P0
9	去外地出差或旅游，不熟悉路線，擔心司機繞遠，費用高。	系統(tǒng)提供高精度的地圖導航，提供即時計費、評價反饋功能，建立誠信機制。	P0
10	平臺派單時間過長，預計接單時間不準，實際等待時間比預計接單時間長很多，甚至沒有司機接單。	系統(tǒng)提供更完善的時間預測算法和司機派單算法；在叫不到車等待時，向乘客顯示等待時間、等待人次、排位順序信息；若超出平臺規(guī)定最長派單時間，提供合理的減免優(yōu)惠。	P0
11	看到附近有空車打不到，接單司機距離太遠，接單接駕時間長。	系統(tǒng)提供更完善的司機派單算法，降低“近單遠接”的概率；做到車輛狀態(tài)信息透明化，明確地向乘客展示車輛處于空駛或是已接單狀態(tài)。	P0
12	聯(lián)系接單司機浪費時間：司機接單后不主動聯(lián)系，只有車輛到達地點后找不到人才聯(lián)系，甚至找不到人也不聯(lián)系，要不在地點等候，要不在周圍繞圈（不方便停車的地方）。	系統(tǒng)提供通知功能，在司機接單后自動向用戶發(fā)送消息告知接單司機及車輛相關信息。	P0
13	車輛到達上車點和實際位置有出入，到達上車點時間不準，導航路線不合理，預計到達目的地時間不準，到達目的地位置不準。	與高質量的地圖服務第三方合作，提供更精準的地圖服務。	P0
14	對司機服務或車輛不滿意。	系統(tǒng)提供評價反饋功能。	P0
15	個人物品落在車內。	通過系統(tǒng)的對話功能聯(lián)系行程司機。	P0

2.1.2.2 司機用戶需求

打車軟件的司機用戶需求與乘客用戶需求之間存在關聯(lián)，現(xiàn)將司機用戶需求總結如表 2：

表 2 打車軟件的司機用戶需求

序號	用戶故事	需求描述	優(yōu)先級
1	不愿意去偏遠地區(qū)接單：路程遠，時間長，而且途中接不到其他單。	系統(tǒng)提供加價功能，激勵司機接單；提供預約打車功能，使司機提前明確接送任務。	P0
2	深夜接單前往偏遠地區(qū)，擔心不安全。	系統(tǒng)提供一鍵報警功能，保障司機安全。	P0
3	看見附近有乘客想打車，但接不到單；系統(tǒng)分配的乘客距離太遠，接單中途被取消訂單。	系統(tǒng)提供更完善的派單算法，降低“近單遠接”的概率。	P0
4	特殊原因暫時不方便接單（如手機即將沒電）。	系統(tǒng)提供拒單功能，并向乘客發(fā)送拒單原因，便于司乘之間的雙向選擇。	P0
5	接單到地點找不到乘客。	系統(tǒng)提供對話功能，方便聯(lián)系乘客。	P0
6	對乘客行為或平臺不滿意。	系統(tǒng)提供評價反饋功能。	P0

2.1.3 功能性需求

基于上述用戶需求，本節(jié)將打車軟件的功能性需求分配至乘客端與司機端。

2.1.3.1 乘客端功能性需求

乘客端主要包括如下功能性需求：

（1）注冊登錄：乘客使用打車軟件進行打車時需要處于登錄狀態(tài)，新用戶需要進行注冊，可以選擇使用手機號碼與驗證碼進行注冊，或者使用微信、QQ等第三方賬號授權登錄。

（2）多樣化打車模式：乘客可以選擇即時打車或預約打車，其中即時打車的打車模式有快車、專車、順風車和拼車；預約打車的打車模式有快車、專車、拼車和個性化打車。多樣化的打車模式滿足更廣大用戶群體的需求。

（3）開銷預算：乘客提交打車請求后，系統(tǒng)會根據(jù)乘客的出發(fā)地和目的地，估算出需要花費的時間及費用，方便司機與乘客。

（4）空車搜索：乘客可以查看附近車輛狀態(tài)（空駛/已接單），方便乘客自選車輛打車。

（5）訂單管理：乘客可以查看歷史訂單。在司機接單后，乘客可以查看當前訂單詳情，了解接單司機的相關信息，包括司機的電話號碼，車牌號碼、車輛型號、司機評價、司機實時位置等。在行程開始前，乘客可以取消訂單。

（6）消息管理：乘客可以接收系統(tǒng)通知及司機消息，可以向司機發(fā)送消息進行聯(lián)系，并且可以查看歷史對話記錄。

（7）即時計費：在乘客上車后計費開始，乘客可以實時查看當前行車路線導航、里程、時間及費用。

（8）一鍵報警：如若遇到危險，乘客可以通過一鍵報警向第三方安全中心求救。

（9）支付：到達目的地后，乘客可以選擇支付寶、微信等第三方支付方式進行支付，同時可以選擇使用優(yōu)惠券、會員積分等獲得減免。

（10）評價：支付完成后，乘客可以對司機的服務進行評價。

上述需求總結如圖 2：

圖 2 乘客端功能性需求

2.1.3.2 司機端功能性需求

司機端主要包括如下功能性需求：

（1）注冊登錄：司機在使用打車軟件時需要處于登錄狀態(tài)，新用戶需要注冊，向系統(tǒng)提交手機號、駕駛證號、本人與車輛合照等信息，審核通過后才能進行接單。

（2）訂單管理：司機在收到系統(tǒng)推送的訂單時，可以選擇接單或拒單。司機選擇接單后可以查看當前訂單詳情，確定乘客的上車地點。另外，司機可以查看歷史訂單信息，方便對工作量的評估。

（3）乘客搜索：司機可以查看附近請求打車的乘客狀態(tài)（未上車/已上車），方便司機自找乘客。

（4）行車導航：司機可以根據(jù)行車導航出發(fā)去接乘客，并且可以通過導航確定從乘客出發(fā)地到目的地的合適路線。

（5）消息管理：司機可以接收系統(tǒng)通知，與乘客對話溝通，并可以查看歷史對話記錄。

（6）一鍵報警：如若遇到危險，司機可以通過一鍵報警向第三方安全中心求救。

（7）評價：訂單結束后，司機可以對乘客進行評價。

（8）收入查詢：司機可以查看載客所收到的報酬，通過綁定銀行卡提現(xiàn)。

上述需求總結如圖 3：

圖 3 司機端功能性需求

2.1.4 非功能性需求

如表 3所示，打車軟件不僅要實現(xiàn)用戶的基本需求，而且在性能、安全性、軟件質量屬性等方面有一定的限制要求。

表 3 打車軟件的非功能性需求

類型	需求描述
性能需求	業(yè)務量：系統(tǒng)滿足多用戶同時工作，保障同時在線用戶數(shù)500W人，并發(fā)操作100W人的使用要求。
	響應時間：在95％的情況下，一般時段響應時間不超過1.5秒，高峰時段不超過4秒。
	精度：地圖定位精度誤差不超過80米。
	系統(tǒng)容量：滿足未來5年業(yè)務數(shù)據(jù)擴展要求。
	資源使用率：CPU占用率<=50%，內存占用率<=50%。
安全性需求	嚴格權限訪問控制，用戶在經過身份認證后，只能訪問其權限范圍內的數(shù)據(jù)，只能進行其權限范圍內的操作。
	提供運行日志管理及安全審計功能，可追蹤系統(tǒng)的歷史使用情況。
	網(wǎng)絡傳遞數(shù)據(jù)應經過加密。需要保證數(shù)據(jù)在采集、傳輸和處理過程中不被偷窺、竊取、篡改。
	能經受來自互聯(lián)網(wǎng)的一般性惡意攻擊，如病毒（包括木馬）攻擊、口令猜測攻擊、黑客入侵等，至少90%的攻擊需要在10秒內檢測到。
軟件質量屬性	易用性：打車軟件面向用戶群體廣泛，為方便老人使用，要求操作簡單，界面美觀，用戶容易上手，體驗良好。
	可靠性：連續(xù)運行一周不得出現(xiàn)閃退或程序未響應的情況。
	健壯性：對于運行過程中出現(xiàn)的各種異常情況，如：人為操作錯誤、輸入非法數(shù)據(jù)、硬件設備失敗等，系統(tǒng)能正確地處理回避。
	效率性：盡可能優(yōu)化通信協(xié)議，減少網(wǎng)速對系統(tǒng)的影響。
	兼容性：可運行于安卓系統(tǒng)2.3.0及以上的各個品牌的智能手機上。
	易集成性：要求代碼精簡、集成度高，易于嵌入美團、高德等互聯(lián)網(wǎng)聚合平臺，有利于后期的發(fā)展。
	可擴展性：軟件采用模塊化設計，接口要標準化，以適應未來功能擴展的需求。
	可測試性：軟件開發(fā)過程中使用回歸測試，交付必須通過100%覆蓋的單元測試。
	可維護性：一個模塊的最大圈復雜度不超過15。
其他需求	軟件需按照公司整體風格進行UI調整、色調調整等。
	軟件需遵守最新法律法規(guī)，根據(jù)所在地區(qū)規(guī)定提供相應的服務。

2.2 系統(tǒng)模型

根據(jù)上述需求分析，本節(jié)采用結構化分析方法（SA, Structure Analysis）中的數(shù)據(jù)流圖（DFD, Data Flow Diagram）定義系統(tǒng)模型。

打車軟件的頂層數(shù)據(jù)流圖如圖 4，系統(tǒng)以乘客、司機、第三方地圖、第三方支付、以及第三方安全中心為邊界。

圖 4 打車軟件頂層數(shù)據(jù)流圖

圖 5 打車軟件一層數(shù)據(jù)流圖

圖 5為打車軟件的一層數(shù)據(jù)流圖，將系統(tǒng)拆分為注冊登錄、搜索、打車、定位導航、開銷預算、派單、訂單管理、即時計費、消息管理、評價、報警、電子支付及收入查詢環(huán)節(jié)。由于該數(shù)據(jù)流圖線條繁雜，在此不再給出其細化后的二層數(shù)據(jù)流圖及數(shù)據(jù)文件，下文的功能設計（3.1節(jié)）與數(shù)據(jù)設計小節(jié)（3.2節(jié)）將對打車軟件的功能與數(shù)據(jù)做進一步設計說明。

3 打車軟件設計方案

本節(jié)將從功能設計、數(shù)據(jù)設計、系統(tǒng)架構、系統(tǒng)部署、關鍵技術五方面介紹打車軟件的設計方案。

3.1 功能設計

對比乘客端與司機端的功能性需求發(fā)現(xiàn)：乘客端與司機端的很多功能是相似的、甚至相同的。因此，相似或相同的功能可并入一個模塊處理。如圖 6，最終整個打車軟件系統(tǒng)可分為個人信息、打車、定位、訂單管理、消息管理五個模塊。

圖 6 打車軟件功能架構

其中，個人信息、定位、訂單管理、消息管理模塊是乘客端與司機端都擁有的，打車模塊是屬于乘客端的。各功能點已在2.1.3節(jié)進行過描述，在此不再贅述。

3.2 數(shù)據(jù)設計

本節(jié)將從數(shù)據(jù)庫概念設計、數(shù)據(jù)庫邏輯設計、數(shù)據(jù)庫物理設計三方面對系統(tǒng)數(shù)據(jù)進行設計。

3.2.1 數(shù)據(jù)庫概念設計

打車軟件系統(tǒng)的E-R圖如圖 7所示，可以看到：一個乘客可以預定和支付多個訂單，一個司機也可以接收多個訂單；但一個司機只能駕駛一輛網(wǎng)約車。另外，司機與乘客之間還存在搭乘、對話及評價關系。

圖 7 打車軟件系統(tǒng)E-R圖

3.2.2 數(shù)據(jù)庫邏輯設計

根據(jù)系統(tǒng)模型，本文為打車軟件系統(tǒng)設計了8個數(shù)據(jù)表，包括乘客信息表、司機信息表、乘客位置表、司機位置表、訂單記錄表、消息記錄表、乘客評價記錄表、司機評價記錄表。各數(shù)據(jù)表的設計結構如下：

• 乘客信息表（passenger）：記錄乘客端用戶的基本信息，乘客用戶注冊時添加的用戶名、密碼、姓名、性別、手機號等基本信息都會存入該表中。該表的主鍵為乘客編號。
• 司機信息表（driver）：記錄司機端用戶的基本信息，司機端用戶注冊時添加的用戶名、密碼、姓名、性別、手機號、身份證號、駕駛證號等基本信息都會存入該表中。該表的主鍵為司機編號。
• 乘客位置表（passenger_location）：記錄當前乘客的位置信息，包括位置編號、經度、緯度、當前時刻、乘客編號、乘客狀態(tài)。該表主鍵為位置編號。
• 司機位置表（driver_location）：記錄當前司機的位置信息，包括位置編號、經度、緯度、當前時刻、司機編號、司機狀態(tài)。該表主鍵為位置編號。
• 訂單記錄表（order）：記錄每次打車訂單的基本信息，包括訂單編號、乘客編號、司機編號、起點、終點、打車時間、上車時間等基本信息。該表主鍵為訂單編號。
• 消息記錄表（message）：記錄乘客與司機的對話信息，包括消息編號、訂單編號、消息發(fā)送者編號、消息接收者編號、消息發(fā)送時間。該表主鍵為消息編號。
• 乘客評價表（passenger_review）：記錄司機給乘客的評價信息，包括評價編號、乘客編號、訂單編號、評價等級、評價內容、評價人編號、評價時間。該表主鍵為評價編號。
• 司機評價表（driver_review）：記錄乘客給司機的評價信息，包括評價編號、司機編號、訂單編號、評價等級、評價內容、評價人編號、評價時間。該表主鍵為評價編號。

3.2.3 數(shù)據(jù)庫物理設計

數(shù)據(jù)庫物理設計的工作是具體化設計數(shù)據(jù)字段名、數(shù)據(jù)類型及相關約束。上述數(shù)據(jù)表的物理設計如下：

表 4 乘客信息表（passenger）-與個人信息模塊相關

編號	字段	數(shù)據(jù)類型	備注
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）-與個人信息模塊相關

編號	字段	數(shù)據(jù)類型	備注
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）-與定位模塊相關

編號	字段	數(shù)據(jù)類型	備注
1	locId	INT(20)	位置編號PK
2	longitude	DOUBLE	經度
3	latitude	DOUBLE	緯度
4	time	TIME	當前時刻
5	passengerId	INT(20)	乘客編號
6	status	INT(2)	乘客狀態(tài)

表 7 司機位置表（driver_location）-與定位模塊相關

編號	字段	數(shù)據(jù)類型	備注
1	locId	INT(20)	位置編號PK
2	longitude	DOUBLE	經度
3	latitude	DOUBLE	緯度
4	time	TIME	當前時刻
5	driverId	INT(20)	司機編號
6	status	INT(2)	司機狀態(tài)

表 8 訂單記錄表（order）-與訂單管理模塊相關

編號	字段	數(shù)據(jù)類型	備注
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)	訂單狀態(tài)

表 9 消息記錄表（message）-與消息管理模塊相關

編號	字段	數(shù)據(jù)類型	備注
1	messageId	INT(20)	消息編號PK
2	orderId	INT(20)	訂單編號
3	senderId	INT(20)	消息發(fā)送者編號
4	receiverId	INT(20)	消息接收者編號
5	time	DATETIME	消息發(fā)送時間

表 10 乘客評價表（passenger_review）-與訂單管理模塊的評價功能相關

編號	字段	數(shù)據(jù)類型	備注
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）-與訂單管理模塊的評價功能相關

編號	字段	數(shù)據(jù)類型	備注
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 系統(tǒng)架構

系統(tǒng)設計采用MVC（Model View Controller）框架模式，這種框架模式以數(shù)據(jù)、界面顯示、業(yè)務邏輯分離的方法組織代碼，在改良和個性化定制界面及用戶交互的同時，不需要重新編寫業(yè)務邏輯，使代碼具有較好的可擴展性、可復用性、可維護性及靈活性。系統(tǒng)架構如圖 8所示，分為三層：前端表現(xiàn)層、業(yè)務邏輯層、物理數(shù)據(jù)層。

圖?8 打車軟件系統(tǒng)架構

其中，前端表現(xiàn)層主要接收用戶請求，并為用戶呈現(xiàn)信息；業(yè)務邏輯層調用模型完成相應的業(yè)務，與數(shù)據(jù)庫聯(lián)動處理增刪改查操作；物理數(shù)據(jù)層用于存儲業(yè)務相關數(shù)據(jù)。

3.4 系統(tǒng)部署

打車軟件基于C/S模型，其乘客端和司機端屬于移動客戶端，客戶端之間通過網(wǎng)絡進行通信，服務器端使用負載均衡和集群化的方式來應對高并發(fā)的業(yè)務需求。系統(tǒng)部署如圖 9。

圖 9 打車軟件系統(tǒng)部署

3.5 關鍵技術

實現(xiàn)打車軟件的關鍵技術如下表 12，包括操作系統(tǒng)、數(shù)據(jù)庫、移動通信技術等：

表 12 打車軟件的關鍵技術

技術類型?	技術點	使用原因
操作系統(tǒng)	客戶端為Andriod/iOS，服務器端為Linux	打車軟件客戶端主要運行在智能手機終端，主流操作系統(tǒng)為Andriod與iOS；服務器端選用Linux，是因其具有穩(wěn)定、安全、易用、費用低的優(yōu)點。
數(shù)據(jù)庫	MySQL、Redis	MySQL用于持久化存儲，Redis用于緩存。
移動通信技術	流量控制、負載均衡、實時通信	應對高并發(fā)、低延遲的業(yè)務需求。
數(shù)據(jù)交換技術	json、壓縮	json常用于數(shù)據(jù)傳輸，為提升傳輸效率，使用壓縮技術。
業(yè)務流程	派單算法、開銷預測算法、計費算法	打車軟件需要專用算法完成業(yè)務流程，派單、開銷預測、計費等環(huán)節(jié)對用戶體驗至關重要。
地圖和定位	空間索引、空間計算	空車搜索、乘客搜索等功能需要對空間數(shù)據(jù)進行高效地查詢。
隱私保護技術	基于位置的K匿名、差分隱私	用戶的位置、運行軌跡等信息屬于個人敏感信息，需要脫敏處理。
安全技術	加密算法	用戶密碼等數(shù)據(jù)不得以明文形式進行傳輸。

4 總結

本文主要對打車軟件進行系統(tǒng)分析和設計，首先使用SA方法及DFD工具進行系統(tǒng)分析，然后使用MVC框架模式進行系統(tǒng)設計，最后指明了打車軟件的系統(tǒng)部署及關鍵技術。

參考文獻

??【1】網(wǎng)約車_百度百科[EB/OL]. https://baike.baidu.com/item/%E7%BD%91%E7%BA%A6%E8%BD%A6. 2020年7月20日訪問.

【2】易觀. 2019中國網(wǎng)約車市場分析報告. 2019年7月.

【3】J.D. Power. 2020中國網(wǎng)約車服務質量研究報告. 2020年3月.

【4】極光大數(shù)據(jù). 2019年1月網(wǎng)約車行業(yè)研究報告. 2019年1月.

【5】德勤咨詢. 十字路口的網(wǎng)約車. 2019年1月.

【6】CNNIC. 第45次中國互聯(lián)網(wǎng)絡發(fā)展狀況統(tǒng)計報告. 2020年4月.

【7】牛偉娜, 馬倩瑤. 我國打車軟件盈利模式探討[J]. 合作經濟與科技, 2016(19):110-111.

【8】極光. 2019年網(wǎng)約車出行安全用戶信心研究報告. 2019年12月.

總結

以上是生活随笔為你收集整理的打车软件系统分析与设计方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。