恒月网约车概要设计.docx
《恒月网约车概要设计.docx》由会员分享，可在线阅读，更多相关《恒月网约车概要设计.docx（23页珍藏版）》请在冰点文库上搜索。
恒月网约车概要设计
编号：
_________________
版本：
_________________
恒月网约车叫车平台
概要设计说明书
[V1.0（第一版）]
编制:
2592431636
审核:
50104694
批准:
2592431636
批准日期：
2020.1
恒月网约车叫车平台概要设计说明书
1引言
1.1编写目的
恒月网约车叫车平台利用移动互联网和大数据技术，创新交通出行服务模式，整合市场资源，搭建起商务用车的信息服务平台，对满足和提升市民多元化出行需求服务，以及促进政府加强资源有效管理、促进城市出行领域交通智能化建设都将产生积极的影响。
我们将这个模块分为服务号开发和企业号开发两块，服务号实现普通教程客户端的功能，包括约车出行，叫车人信息，我的行程等功能的开发，而约车是整个开发的重点，包括对微信服务号和微信企业号的开发：
1.2背景
待开发的项目系统的名称：
恒月网约车叫车平台
项目的任务提出者：
2592431636
项目开发者：
恒月畅游公司技术部
用户：
项目管理人员系统分析人员程序员
质量工程师测试人员其他相关人员
需要打车的用户和希望成为网约车的有车人群
实现该项目的计算机网络：
移动互联网
1.3定义
“项目”：
本文中的项目即指的是网约车叫车平台
“甲方公司”：
恒月汽车服务有限公司
“乙方公司”：
恒月畅游
“WCF”：
WindowsCommunicationFoundation
1.4参考资料
1.《项目工程基础》赵一丁北京邮电大学出版社
2.《项目需求》劳森（作者）,刘晓晖（译者）电子工业出版社
3.《项目需求工程：
原理和方法》金芝，刘璘，金英科学出版社
4.需求主要来自《恒月汽车信息咨询服务协议》
5.《网络预约出租汽车经营服务管理暂行办法》
6.《互联网信息服务管理办法》国务院令第292号
2总体设计
按功能不同进行技术层次划分，使各层功能相对独立。
同时以接口形式来描述各层之间的调用关第，以达到层次之间的松散耦合。
各层所提供功能不依赖于一种具体的技术或产品实现，应该提供一定范围的技术选择。
技术架构不和具体的应用架构绑定，应具备较宽的使用范围，适合未来应用的扩展。
以下为总体模块之间的关系：
2.1需求规定
1．系统用户登陆通过与用户手机号和微信绑定进行认证
2．创意产品研发过程对选取司机使用手机短信通知功能
3．遵循海豹平台开发规范。
使用Yii2.0框架作为开发平台。
4．遵循腾讯编码规范。
2.2运行环境
服务器硬件设备说明。
配置包括：
a．处理器型号Intel（R）Xeon（R）CPUE5-2403v2@1.80GHz4核；
b．内存8GB；
c．Memcache缓存服务器1台；
d．服务器硬盘1TB；
开发采用使用Apache2.4.9MySQL5.6.17PHP5.5.12以上环境。
2.3基本设计概念和处理流程
恒月网约车叫车平台各层所提供功能不依赖于一种具体的技术或产品实现，应该提供一定范围的技术选择。
以下为总体模块之间的关系：
●用户注册流程：
点击免费获取验证码后，按钮不可用，进入60s倒计时；60s后按钮重新激活；
服务器下发验证码限制：
1.60s后可以重发；
2.每天每个帐号上限3条
点击确定，进入下一步
默认提示：
请输入原始密码；请输入8-20位新密码；请确认输入新密码
点击确定，提示“恭喜您，您已经注册！
●支付运行流程：
以上是网约车平台支付场景的交互细节：
（1）用户打发起支付，在网页通过JavaScript调用getBrandWCPayRequest接口，发起微信支付请求，用户进入支付流程。
（2）用户成功支付点击完成按钮后，前端会收到JavaScript的返回值。
公司可直接跳转到支付成功的静态页面进行展示。
（3）公司后台收到来自微信开放平台的支付成功回调通知，标志该笔订单支付成功。
注：
（2）和（3）的触发不保证遵循严格的时序。
JSAPI返回值作为触发商户网页跳转的标志，但商户后台应该只在收到微信后台的支付成功回调通知后，才做真正的支付成功的处理。
JSAPI返回值目前只在支付成功时返回，后续版本将扩展返回值，以便商户做更多个性化的展示。
●接口安全令牌获取流程
安全令牌处理程序负责创建、读取、写入和验证令牌。
令牌处理程序集合用于接管WCF所使用的令牌管理器的部分责任。
WIF可将安全令牌处理程序集合插入到WCF管道中。
WIF令牌处理程序提供单个扩展点，用于添加对其他令牌类型的支持，还用于自定义如何处理WIF默认情况下支持的令牌类型。
2.4结构
2.4.1网约车平台产品系统的层次模型
项目以车辆硬件，无线网络，gps，以及服务器等基础设施作为支持，通过软硬件接口做数据支持，通过时间表单对数据进行调用，返回定位等信息，通过各种算法实现网约车平台约车，叫车等功能。
2.4.1.1应用层客户端（ClientTier）
应用层客户端指的是访问应用的web浏览器终端，通过web浏览器啊来访问创新综合管理系统。
该层的展示效果应遵循我行《BS架构系统用户界面规范》
2.4.1.2表现层（PresentationTier）
表现层接收客户端的HTTP请求，提供系统登陆，会话管理，访问控制，数据封装和交易分发等功能。
采用微信sdk时，应遵循微信sdk技术实施规范。
2.4.1.3业务控制层（UsecaseControllerTier）
对表示层发来的数据格式进行检查判断，根据不同的业务将数据分配到不同的业务处理服务进行处理。
2.4.1.4业务服务层（BusinessServiceTier）
业务层是J2EE构架的核心层，它接收展示层分发的交易请求，完成业务逻辑的具体实现。
对不同的业务数据进行处理，处理完成后，将处理结果返回表现层。
2.4.1.5集成层（InterfaceTier）
集成层向业务层提供统一的内部和外部资源访问，为业务层的数据访问请求屏蔽不同的数据存储访问技术，以及与外部系统整合技术的差异性。
2.4.1.6数据层（ResourceTier）
资源层主要指数据库、文件系统和外部系统。
该层采用的产品遵循总行信息技术管理部对数据库等项目产品的统一规定。
本系统采用mysql作为数据库系统。
2.4.2物理部署构架：
2.5功能与程序的关系
本项目功能需求关系表：
一级模块
模块
主要功能点
微信基本接口开发
回复接口
预先设置好客户所需问题的答案进行推送（咨询、询问）
支付接口
用户自行申请微信支付资格，微客来提供接口对接
消息模版
对于每次产生的叫车，接车，支付状态及时提示微信消息
提现接口
为司机提供提现功能
成员信息读取
区分用户等级，为不同类型用户提供不同的服务
腾讯地图接口
gps定位
实时追踪用户和车的地理位置
路程计算
为行车计算里程数
智能导航
为司机端和用户端提供智能的行程导航
消费公式
设立里程数，奖励金，等待时间等产生的资费公司
企业号作为司机端
出车状态修改
方便司机修改出车状态
抢单接单
实时抢单系统，根据司机状态推送
提现
司机每周三可以实现提现
接单状态
系统判断司机的接单状态
出车状态
司机手动改版自身的行车状态，可以调整为不接单
服务号用户端
用户下单
客户填写信息，提交叫车订单
行程跟踪
对用户的行程做及时的gps定位跟踪
订单查询
对以往订单做查询
订单状态
当前订单的状态查询，包括司机已接单，未接单，支付状态等
快车叫车
快车模式叫车
顺风车叫车
顺风车模式叫车
行程管理
对行程判断，包括到达开始地点，到达指定地点等
我的信息
我自己的信息记录，支付表，行程记录等
2.6人工处理过程
无
2.7尚未问决的问题
无
3接口设计
3.1用户接口
3.1.1用户叫车模块
系统名：
网约车叫车平台
编制者：
50104694
模块名：
用户叫车模块
编号：
01
由哪些模块调用：
我的行程，司机抢单
调用哪些模块：
腾讯地图接口
输入：
到达地址
输出：
叫车订单信息
算法说明：
If到达地址存在
返回确认是否叫车
If确认
生成叫车订单
Else取消订单
Else返回地址错误信息提示
3.1.2我的行程模块
系统名：
网约车叫车平台
编制者：
50104694
模块名：
我的行程模块
编号：
02
由哪些模块调用：
微信用户信息
调用哪些模块：
用户叫车
输入：
查询事件
输出：
行程列表数据
算法说明：
If用户已经登录
生成用户订单列表
Else返回用户登录提示
3.1.3用户信息模块
系统名：
网约车叫车平台
编制者：
50104694
模块名：
用户信息模块
编号：
03
由哪些模块调用：
用户叫车
调用哪些模块：
微信用户信息
输入：
姓名手机号
输出：
用户类型
算法说明：
If手机号存在
返回验证码
If验证码正确
填写用户姓名，返回用户类型
Else提示验证失败
Else返回手机错误
3.2外部接口
与微信接口关系如图：
3.3内部接口
说明本系统之内的各个系统元素之间的接口的安排。
4运行设计
4.1运行模块组合
如图：
服务号主要是用于实现用户叫车功能，可以任务是一个简单的叫车客户端
叫车功能研究中我们主要结合了微信的gps接口和腾讯地图的接口，以及每辆车上面的gps，做预约车，叫车人之间的位置定位关系。
我们通过获取叫车人的gps，作为默认的出发点，同时也对出发点做了输入提示功能。
并将用户叫车的手机号码作为唯一标识，采用短信认证的方式。
这个通过微信服务号叫车的过程，实现了对微信平台多接口调用，并达到了叫车的目的。
而对于企业号，根据企业号属于私密，群发无限制等特点，将其作为司机接单端来管理。
对面每个用户的叫单，在企业号里面都会有信息提示，企业号采用抢单机制，即判断司机的点击时间，对于第一时间打开消息的司机，系统判断为接单成功。
除了以上关键方面研究外，我们还对用户收款，司机提现，行车距离计算，行车费用计算，接单状态等多方面进行了研发，最终完成了叫车模块的所有功能，达到了叫车需求。
4.2运行控制
具体项目的运行模块组合为多个浏览器并发交互的运行环境，各个模块在项目运行过程中能较好的交换信息，处理数据。
当用户登录到系统时，用户输入的数据通过微信浏览器或手机终端传输到服务器端，由后台的管理模块对输入进行验证，终端接收服务器返回的信息，终端接收服务器返回的用户信息，给不同的用户展示不同的界面。
司机在终端上对订单信息进行操作，提交数据给服务器后，服务器校验数据，服务器返回提交结果给浏览器，是否修改成功。
用户在终端使用本系统时，能够见到漂亮清晰地界面，简单的操作流程。
4.3运行时间
a．响应时间不大于5000毫秒；
b．用户（叫车用户和司机端用户）数据更新处理时间不大于2000毫秒；
c．数据的转换和传送时间不大于2000毫秒；
d．整体运算时间不大于1000毫秒。
5系统数据结构设计
5.1逻辑结构设计要点
模块
叫车用户
司机用户
用户管理
系统管理
回复接口
√
支付接口
√
消息模版
√
提现接口
√
成员信息读取
√
gps定位
√
路程计算
√
智能导航
√
消费公式
√
出车状态修改
√
抢单接单
√
提现
√
接单状态
√
出车状态
√
用户下单
√
行程跟踪
√
√
订单查询
√
√
订单状态
√
√
快车叫车
√
顺风车叫车
√
行程管理
√
√
我的信息
√
√
5.2物理结构设计要点
系统信息表主要与系统框架有关的系统表，包括：
中文表名
英文表名
数据字典表
netcar_dictionary
流转基础表
netcar_main_form
附件表
netcar_attachment
后台管理员表
netcar_adminuser
后台管理员日志表
netcar_admin_log
银行表
netcar_bank
司机表
netcar_driver
司机订单表
netcar_driverorder
司机银行卡表
netcar_driver_bank
支付公式表
netcar_gongshi
用户订单表
netcar_order
包车订单表
netcar_rentsorder
临时用户表
netcar_tmpuser
用户表
netcar_user
订单完成情况及收益表
netcar_finish_circs
通知信息记录表
netcar_notice
5.3数据结构与程序的关系
1、用户表
2、临时用户表
3、后台管理员
4、司机表
5、司机订单表
6、包车订单表
6系统出错处理设计
6.1出错信息
错误类型
原因
解决办法
数据库连接错误
数据库设置不正确或mysql异常
取消本次操作，提醒用户检查数据库
输入错误
输入不规范
通过对话框，提醒用户，然后再次操作
不可预知错误
未知异常
进行数据库备份，帮助开发者完善程序
6.2补救措施
我们对于本程序的几种可能的错误进行了分析，分别进行了不同的处理。
主要的错误可能有：
数据库连接错误：
这类错误主要是数据库设置不正确，或MYSQL异常引起的，我们只要取消本次操作，提醒用户检查数据库问题就可。
输入错误：
这主要是用户输入不规范造成的，我们在尽量减少用户出错的条件的情况下，主要也是通过对话框，提醒用户，然后再次操作。
其他操作错误：
对于用户的不正当操作，有可能使程序发生错误。
我们主要是中止操作，并提醒用户中止的原因和操作的规范。
其他不可预知的错误：
程序也会有一些我们无法预知或没考虑完全的错误，我们对此不可能作出安全的异常处理，这时我们主要要保证数据的安全，所以要经常的进行数据库备份，并能及时的和我们联系，以逐步的完善我们的程序。
6.3系统维护设计
项目的维护主要包括数据库的维护和管理子系统服务器的维护。
对于数据库的维护，需要提供数据库的备份和恢复功能，方便地实现数据库的维护和管理。
对于管理子系统服务器的维护，由于每个模块之间的独立性较高，对服务器的维护带来了很大方便。
对于功能的添加，只需要再添加菜单项内容即可，我们将根据客户的要求和反应，定期对项目进行维护和改进。
升级会员 