摘要 本文是笔者软件工程与方法课的课程作业,从中国网约车行业的发展历程及市场现状出发,立足于当下市场需求,以期设计一款具有市场竞争力的打车软件。本文首先对打车软件进行需求分析,然后采用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月.