互联网+洗衣服务系统总体设计

　　第 4 章 平台总体设计

　　通过第三章需求分析可知，网上洗衣服务平台具有数据操作量大、用户和数据库交互频繁、数据实时性要求较高等特点，选择合适的平台架构及实现技术进行项目开发很重要。本章将对其分层架构进行设计，对主要功能模块划分以及数据库设计。

　　本章内容如下安排：第 1 节对平台的分层架构进行设计；第 2 节首先对运营管理端功能进行划分，其次对微信端功能进行划分；第 3 节对平台的数据库进行设计，主要是对平台的数据库表进行设计。

　　4.1 平台分层架构设计。

　　本平台采用基于 J2EE 分层思想的 SSM 框架技术进行平台设计。主要包含四层，分别是表示层、控制层、业务逻辑层和数据持久层。表示层给用户提供操作界面，用户通过界面向平台发出数据请求。表示层主要通过 JSP 技术构建页面，使用 Easy-UI 框架技术和 JFreeChart 等技术丰富页面元素，同时使用 Ajax 和 Post 等方法响应用户请求。

　　控制层主要是采用 Struts 框架实现，在该层设计中，需要编写 Action 类。在配置文件中定义拦截器，以及文件上传控件。控制层在表现层和业务层两者间主要起到关联作用。控制层根据用户请求调用业务层中相应的方法，并将处理结果通过 Post 等方法返回至表示层。

　　业务逻辑层采用 Spring 框架实现，在该层主要完成的是 Service 接口的编写和接口的具体实现，例如微信接口，用于获取验证码的 Submail 短信服务，用于支付的 Ping++支付接口以及配送端的 jPush 安卓通知推送，还有运营管理端中定时生成报表的 Quartz 定时控制和 Excel 生成的实现。业务逻辑层是整个架构的核心部分，在该层主要是对输入的数据进行逻辑处理，并将结果返回。

　　数据持久层（数据访问层）采用 MyBatis 框架技术实现，在配置文件中配置JDBCTemple 和数据库连接池，实现 Mapper 接口和持久层与 SQL 的映射关系。持久层主要是为业务层提供接口，在调用接口时，数据持久层会通过映射关系访问数据库。

　　

　　4.2 平台功能划分。

　　通过 3.2.2 节对平台功能性需求分析得知，运营管理端被划分成：用户管理、订单管理等五个功能模块，微信端包含用户登录、用户下单、余额充值、订单付款等功能。在运营管理端，本文作者被分配到负责价格体系和充值卡管理功能、订单修改和关闭功能以及订单审核等功能的设计。微信端，被分配到负责订单付款等功能的设计。下面将用 UML 序列图的方式对这些功能进一步的分析。

　　4.2.1 运营管理端。

　　1、价格体系管理。

　　价格体系管理是对多种用户组设定不同的价格体系，让用户享受不一样的洗衣价格。设定价格体系的首要前提是用户组必须存在。价格体系管理中有查询、添加、编辑和删除价格体系的功能，最主要的是添加价格体系功能。添加价格体系功能实现包括如下部分：

　　输入内容：选择用户组、要设定价格的服务以及服务的价格和数量等内容。处理流程：检验输入的内容是否符合格式要求，例如价格是否是大于 0 的正数，用户组是否存在等；添加成功后可在列表中查询。数据输出：向管理员弹出添加成功的提示框。

　　价格体系添加的 UML 序列图如图 4.2 所示：

　

　　2、充值卡管理。

　　充值卡管理是对充值卡进行管理，包括充值卡的添加、查询以及使用充值卡和现金充值。充值卡的添加有单个添加和批量添加两种，批量添加是通过文件的上传下载来添加的，即下载模板和上传带有数据的充值卡文件，数据内容中卡号要求不能重复。为了保证数据的安全性和一致性，当文件中存在相同的卡号或文件中存在和平台中一样的卡号时，所有数据都会上传失败。

　　（1）批量添加充值卡功能实现如下：

　　输入内容：输入带有数据信息的模板文件。

　　处理流程：检验内容是否符合要求，例如文件中数据格式是否正确、是否存在相同卡号等。

　　数据输出：向管理员返回添加成功的提示框，列表中增加了充值卡数据。

　　单个添加充值卡与批量添加充值卡类似，只是输入内容不一样，单个添加充值卡是直接输入充值卡号、密码、面值和时效等内容。批量添加充值卡的 UML序列图如图 4.3 所示。

　　

　　（2）使用充值卡给用户充值功能实现如下：

　　输入内容：手机号、充值卡号和密码。

　　处理流程：检验输入内容格式是否符合要求，例如手机号是否正确、充值卡是否使用、卡号是否存在、卡号和密码是否匹配等；用户余额是否变化。

　　数据输出：向管理员返回结果，充值卡状态改为“已使用”，用户余额增加。

　　使用充值卡充值功能的 UML 序列图如图 4.4 所示。

　　

　　3、修改订单信息。

　　管理员对订单的用户信息和价格进行修改，然后交由平台对格式等进行验证，通过即可修改成功。功能实现包括：

　　输入内容：订单价格、修改原因、用户名、地址等信息。

　　处理流程：检验修改的内容是否符合要求；订单表中订单信息修改成功。

　　数据输出：向管理员弹出修改成功提示。

　　修改订单功能的 UML 序列图如图 4.5 所示。

　　

　　4、审核订单。

　　输入内容：选择服务范围，即确定服务门店。

　　处理流程：检验用户信息、订单信息、是否在服务范围等；核查审核过后该订单是否从列表中删除；核查订单状态是否是“抢单中”。

　　输出数据：向客服弹出审核成功提示，订单状态改为“抢单中”。

　　审核订单功能的 UML 序列图如图 4.6 所示。

　　

　　4.2.2 微信端。

　　1、用户登录：用户通过手机号，获取验证码，将使用手机号+验证码的方式登录并同时完成注册。

　　输入内容：输入正确的手机号，获取验证码，输入验证码。

　　处理流程：检验手机号是否符合规则；验证码和手机号是否匹配。

　　输出数据：登录成功，跳转到微信公众号主页。

　　用户登录功能的 UML 序列图如图 4.7 所示。

　　

　　2、余额充值：多种方式中，微信支付使用最多。充值可以给自己充值，也可以给他人充值。给自己余额充值时，只需输入金额。当给朋友充值时，需要输入正确的用户手机号和金额。下面以给朋友余额充值为例，流程如下：

　　输入内容：输入对方正确的手机号，输入金额。

　　处理流程：检验用户手机号是否符合规则；检验金额是否合理。

　　输出数据：充值成功，用户余额增加。

　　使用微信支付给朋友充值功能的 UML 序列图如图 4.8 所示。

　　

　　3、订单支付：订单支付可以用余额和微信支付完成。以微信支付为例，流程如下：

　　输入内容：输入金额。

　　处理流程：检验订单状态是否已完成；检验微信余额是否满足支付订单金额。

　　输出数据：支付成功，订单状态为已支付。

　　订单支付功能的 UML 序列图如图 4.9 所示。

　　

　　4.3 数据库设计。

　　数据库主要是实现平台中数据的存储和管理，是平台能够正常运行的基础。

　　数据库设计的目的是为了更好的存储数据。在进行数据库的设计时需要遵循一些数据库设计的原则，例如安全性等，从而设计出更好的数据库。

　　4.3.1 数据库表设计。

　　遵循数据库设计原则，经过项目团队对平台整体功能讨论，共同对数据库表进行设计，共整理出 30 余张表，包括 tblcustomer（客户表），tblbusiness（商户表），tblcustomeraddress（客户地址表），tblbalancelog（余额日志表），tblcards(充值卡表），tblrole（角色表），tblorder（订单表）等。运营管理端主要是管理数据，因此涉及平台中所有表，本文作者主要负责包含用户表、订单表在内的 6 张表。以及微信端付款功能涉及到余额日志、订单和用户表 3 张表。下面将对主要表进行设计，其余表不再赘述。

　　1、运营管理端数据库表设计。

　　（1）用户管理模块的数据库表设计。

　　根据前面对功能需求的分析，可以总结出该模块主要涉及表有：用户表、商户表、用户组表等七张表，本文作者主要负责价格体系表、充值卡表设计。

　　a、价格体系表。系统中有一组默认价格体系，新的价格体系是在洗衣服务原有价格体系上打折，所以，价格体系表除了修改后的价格属性外，还包含折扣属性。价格体系表如下表 4.1 所示：

　　

　　b、充值卡表。该表主要用来存储充值卡的基本属性，包括充值卡编号、充值卡号、密码、面额等，充值卡也分为卡片式和电子两种，电子充值卡支持下载售出，只能出售一次，因此，属性中包括卡片类型和下载状态。充值卡表如下表4.2 所示：

　　

　　通过结合团队对数据库表的设计以及对业务需求的分析，可以得出用户管理模块中 E-R 图如图 4.10 所示：

　　

　　从 E-R 图中可以直观的看出各实体间的关联关系。用户和商户之间是 1 对1 的关系，选择将商户的主键商户序号加入到用户中；用户和用户组是 1 对 1 的关系，将用户组的主键用户组序号存入到用户表中；用户和余额日志是 1 对多的关系，选择用户的主键用户序号加入到余额日志表中；用户和地址是 1 对多的关系，将用户表中的主键用户序号加入到用户地址表中；用户和充值卡是 1 对多的关系，将用户表的主键用户序号；用户组和价格体系是 1 对 1 的关系，将用户组的用户组序号。由此得出相关表的新增的属性。

　　（2）订单管理模块数据库设计。

　　通过第三章对该模块需求分析看出，该模块主要涉及的表：门店表、订单表、事件表和超时表等。本文作者主要负责订单表、事件表和超时表的设计。

　　a、订单表。订单表较复杂，包含订单的基本信息，如订单号、订单金额等。

　　还需要记录订单的下单时间、审核时间以及订单最终完成时间，同时结合订单状态，完成订单状态的记录。如下表 4.3。

　　

　　b、事件表。事件表的属性包括订单的操作时间、原始状态、操作后的状态、操作人员以及操作时间。如下表 4.4 所示。

　　

　　c、超时表。超时表用于记录订单的超时时间点、超时时长、超时环节等属性。如下表 4.5 所示。

　

　　同时结合其他成员对该模块中其他表的设计得出，订单管理模块的 E.R 图如图 4.11 所示：

　　

　　从 E-R 图中可以直观的看出各实体间的关联关系。门店和订单之间是 1 对多的关系，将门店表的主键门店序号存入订单表中；客户和订单是 1 对多的关系，将客户的主键客户序号存入到订单表中。订单和超时是 1 对多的关系，将订单的主键订单序号存入到超时表中。订单和事件是 1 对多的关系，将订单的主键订单序号存入到事件表中。可以得出相关表的新增属性。

　　（3）客服管理模块数据库设计。

　　通过需求分析可以总结出，该模块共涉及订单表、服务区域表，用户表和用户地址表等六张表，订单表与订单管理模块产生了数据交叉，在此不再赘述。在该模块中，本文作者主要负责服务区域（分配区域）表的设计。分配区域表主要包括区域名、用户是否可见等属性。如下表 4.6。

　　

　　通过对业务需求的分析以及结合其他成员在该模块中对其他表的设计得出，客服管理模块的 E-R 图如下图 4.12 所示：

　　

　　从 E-R 图中可以直观的看出各实体间的关联关系。员工和角色之间是多对多的关系，为了遵循数据库设计的可扩展性和规范化，选择新建一张员工和角色的关联表-员工角色表，将员工和角色表的主键；订单和分配区域表是 1 对 1 的关系，将分配区域的主键区域序号序号作存入到订单表中；用户和订单是 1 对 1的关系，选择用户的主键用户序号加入到订单表；订单和地址是 1 对 1 的关系，将地址表中的主键地址序号加入到订单表中；由此得出相关表的新增的属性。

　　2、微信端数据库表设计。

　　通过 4.2.2 节中微信端功能的划分发现，用户表主要负责存储用户的基本属性，用户通过手机号登录，因此，属性中应包含手机号，且唯一。用户的来源包括几个方面：通过运营后台充值注册、微信端注册等，因此，增加一列用户来源列。还包括注册时的密码、账户余额以及是否为商户。用户表如下表 4.7 所示。

　

　　使用微信支付给余额充值时，余额日志表会发生变化，因此，涉及用户余额日志表，如表 4.8 所示，记录用户余额的变化，包括原始余额、操作后余额等。

　　

　　使用微信支付给订单付款，涉及到订单表、用户表，同时订单付款成功，订单状态发生变化，生成订单操作事件，因此，涉及事件表。这三张表在前面部分已经完成设计，在此不做赘述。微信端部分 E-R 图如图 4.13 所示。

　　

　　平台中由其他成员负责的表设计亦是如此，经过对所有的表进行设计之后，得到平台中表之间的关系模型如图 4.14 所示：

　　

　　4.4 本章小结。

　　本章根据需求分析，对平台进行架构设计，功能划分和数据库设计。在架构设计方面，阐述了分层架构设计。在功能划分部分，描述了运营端和微信端中由本文作者负责的功能设计。在数据库设计方面，主要描述了用户表、订单表等 10余张表的设计。以上三方面设计为平台的实现打下了良好的基础。