互联网+洗衣服务系统总体设计,软件工程硕士论文.docx

《互联网+洗衣服务系统总体设计,软件工程硕士论文.docx》由会员分享，可在线阅读，更多相关《互联网+洗衣服务系统总体设计,软件工程硕士论文.docx（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、互联网+洗衣服务系统总体设计,软件工程硕士论文本篇论文目录导航：【题目】【第一章】【第二章】【第三章】【第四章】 互联网+洗衣服务系统总体设计【5.1-5.2】【5.3-5.4】【6.1-6.4】【6.5-6.7】【以下为参考文献】 第 4 章 平台总体设计 通过第三章需求分析可知，网上洗衣服务平台具有数据操作量大、用户和数据库交互频繁、数据实时性要求较高等特点，选择适宜的平台架构及实现技术进行项目开发很重要。本章将对其分层架构进行设计，对主要功能模块划分以及数据库设计。 本章内容如下布置：第 1 节对平台的分层架构进行设计；第 2 节首先对运营管理端功能进行划分，其次对微信端功能进行划分；第

2、 3 节对平台的数据库进行设计，主要是对平台的数据库表进行设计。 4.1 平台分层架构设计。 本平台采用基于 J2EE 分层思想的 SSM 框架技术进行平台设计。主要包含四层，分别是表示层、控制层、业务逻辑层和数据持久层。表示层给用户提供操作界面，用户通过界面向平台发出数据请求。表示层主要通过 JSP 技术构建页面，使用 Easy-UI 框架技术和 JFreeChart 等技术丰富页面元素，同时使用 Ajax 和 Post 等方式方法响应用户请求。 控制层主要是采用 Struts 框架实现，在该层设计中，需要编写 Action 类。在配置文件中定义拦截器，以及文件上传控件。控制层在表现层和业务

3、层两者间主要起到关联作用。控制层根据用户请求调用业务层中相应的方式方法，并将处理结果通过 Post 等方式方法返回至表示层。 业务逻辑层采用 Spring 框架实现，在该层主要完成的是 Service 接口的编写和接口的详细实现，例如微信接口，用于获取验证码的 Submail 短信服务，用于支付的 Ping+支付接口以及配送端的 jPush 安卓通知推送，还有运营管理端中定时生成报表的 Quartz 定时控制和 Excel 生成的实现。业务逻辑层是整个架构的核心部分，在该层主要是对输入的数据进行逻辑处理，并将结果返回。 数据持久层数据访问层采用 MyBatis 框架技术实现，在配置文件中配置J

4、DBCTemple 和数据库连接池，实现 Mapper 接口和持久层与 SQL 的映射关系。持久层主要是为业务层提供接口，在调用接口时，数据持久层会通过映射关系访问数据库。 4.2 平台功能划分。 通过 3.2.2 节对平台功能性需求分析得知，运营管理端被划分成：用户管理、订单管理等五个功能模块，微信端包含用户登录、用户下单、余额充值、订单付款等功能。在运营管理端，本文作者被分配到负责价格体系和充值卡管理功能、订单修改和关闭功能以及订单审核等功能的设计。微信端，被分配到负责订单付款等功能的设计。下面将用 UML 序列图的方式对这些功能进一步的分析。 4.2.1 运营管理端。 1、价格体系管理。

5、 价格体系管理是对多种用户组设定不同的价格体系，让用户享受不一样的洗衣价格。设定价格体系的首要前提是用户组必须存在。价格体系管理中有查询、添加、编辑和删除价格体系的功能，最主要的是添加价格体系功能。添加价格体系功能实现包括如下部分： 输入内容：选择用户组、要设定价格的服务以及服务的价格和数量等内容。处理流程：检验输入的内容能否符合格式要求，例如价格能否是大于 0 的正数，用户组能否存在等；添加成功后可在列表中查询。数据输出：向管理员弹出添加成功的提示框。 价格体系添加的 UML 序列图如此图 4.2 所示： 2、充值卡管理。 充值卡管理是对充值卡进行管理，包括充值卡的添加、查询以及使用充值卡和

6、现金充值。充值卡的添加有单个添加和批量添加两种，批量添加是通过文件的上传下载来添加的，即下载模板和上传带有数据的充值卡文件，数据内容中卡号要求不能重复。为了保证数据的安全性和一致性，当文件中存在一样的卡号或文件中存在和平台中一样的卡号时，所有数据都会上传失败。 1批量添加充值卡功能实现如下： 输入内容：输入带有数据信息的模板文件。 处理流程：检验内容能否符合要求，例如文件中数据格式能否正确、能否存在一样卡号等。 数据输出：向管理员返回添加成功的提示框，列表中增加了充值卡数据。 单个添加充值卡与批量添加充值卡类似，只是输入内容不一样，单个添加充值卡是直接输入充值卡号、密码、面值和时效等内容。批量

7、添加充值卡的 UML序列图如此图 4.3 所示。 2使用充值卡给用户充值功能实现如下： 输入内容：手机号、充值卡号和密码。 处理流程：检验输入内容格式能否符合要求，例如手机号能否正确、充值卡能否使用、卡号能否存在、卡号和密码能否匹配等；用户余额能否变化。 数据输出：向管理员返回结果，充值卡状态改为 已使用 ，用户余额增加。 使用充值卡充值功能的 UML 序列图如此图 4.4 所示。 3、修改订单信息。 管理员对订单的用户信息和价格进行修改，然后交由平台对格式等进行验证，通过即可修改成功。功能实现包括： 输入内容：订单价格、修改原因、用户名、地址等信息。 处理流程：检验修改的内容能否符合要求；订

8、单表中订单信息修改成功。 数据输出：向管理员弹出修改成功提示。 修改订单功能的 UML 序列图如此图 4.5 所示。 4、审核订单。 输入内容：选择服务范围，即确定服务门店。 处理流程：检验用户信息、订单信息、能否在服务范围等；核查审核过后该订单能否从列表中删除；核查订单状态能否是 抢单中 。 输出数据：向客服弹出审核成功提示，订单状态改为 抢单中 。 审核订单功能的 UML 序列图如此图 4.6 所示。 4.2.2 微信端。 1、用户登录：用户通过手机号，获取验证码，将使用手机号+验证码的方式登录并同时完成注册。 输入内容：输入正确的手机号，获取验证码，输入验证码。 处理流程：检验手机号能否

9、符合规则；验证码和手机号能否匹配。 输出数据：登录成功，跳转到微信公众号主页。 用户登录功能的 UML 序列图如此图 4.7 所示。 2、余额充值：多种方式中，微信支付使用最多。充值能够给自个充值，可以以给别人充值。给自个余额充值时，只需输入金额。当给朋友充值时，需要输入正确的用户手机号和金额。下面以给朋友余额充值为例，流程如下： 输入内容：输入对方正确的手机号，输入金额。 处理流程：检验用户手机号能否符合规则；检验金额能否合理。 输出数据：充值成功，用户余额增加。 使用微信支付给朋友充值功能的 UML 序列图如此图 4.8 所示。 3、订单支付：订单支付能够用余额和微信支付完成。以微信支付为

10、例，流程如下： 输入内容：输入金额。 处理流程：检验订单状态能否已完成；检验微信余额能否知足支付订单金额。 输出数据：支付成功，订单状态为已支付。 订单支付功能的 UML 序列图如此图 4.9 所示。 4.3 数据库设计。 数据库主要是实现平台中数据的存储和管理，是平台能够正常运行的基础。 数据库设计的目的是为了更好的存储数据。在进行数据库的设计时需要遵循一些数据库设计的原则，例如安全性等，进而设计出更好的数据库。 4.3.1 数据库表设计。 遵循数据库设计原则，经过项目团队对平台整体功能讨论，共同对数据库表进行设计，共整理出 30 余张表，包括 tblcustomer客户表，tblbusin

11、ess商户表，tblcustomeraddress客户地址表，tblbalancelog余额日志表，tblcards(充值卡表，tblrole角色表，tblorder订单表等。运营管理端主要是管理数据，因而牵涉平台中所有表，本文作者主要负责包含用户表、订单表在内的 6 张表。以及微信端付款功能牵涉到余额日志、订单和用户表 3 张表。下面将对主要表进行设计，其余表不再赘述。 1、运营管理端数据库表设计。 1用户管理模块的数据库表设计。 根据前面对功能需求的分析，能够总结出该模块主要牵涉表有：用户表、商户表、用户组表等七张表，本文作者主要负责价格体系表、充值卡表设计。 a、价格体系表。系统中有一组

12、默认价格体系，新的价格体系是在洗衣服务原有价格体系上打折，所以，价格体系表除了修改后的价格属性外，还包含折扣属性。价格体系表如下表 4.1 所示： b、充值卡表。该表主要用来存储充值卡的基本属性，包括充值卡编号、充值卡号、密码、面额等，充值卡也分为卡片式和电子两种，电子充值卡支持下载售出，只能出售一次，因而，属性中包括卡片类型和下载状态。充值卡表如下表4.2 所示： 通过结合团队对数据库表的设计以及对业务需求的分析，能够得出用户管理模块中 E-R 图如此图 4.10 所示： 从 E-R 图中能够直观的看出各实体间的关联关系。用户和商户之间是 1 对1 的关系，选择将商户的主键商户序号参加到用户

13、中；用户和用户组是 1 对 1 的关系，将用户组的主键用户组序号存入到用户表中；用户和余额日志是 1 对多的关系，选择用户的主键用户序号参加到余额日志表中；用户和地址是 1 对多的关系，将用户表中的主键用户序号参加到用户地址表中；用户和充值卡是 1 对多的关系，将用户表的主键用户序号；用户组和价格体系是 1 对 1 的关系，将用户组的用户组序号。由此得出相关表的新增的属性。 2订单管理模块数据库设计。 通过第三章对该模块需求分析看出，该模块主要牵涉的表：门店表、订单表、事件表和超时表等。本文作者主要负责订单表、事件表和超时表的设计。 a、订单表。订单表较复杂，包含订单的基本信息，如订单号、订单

14、金额等。 还需要记录订单的下单时间、审核时间以及订单最终完成时间，同时结合订单状态，完成订单状态的记录。如下表 4.3。 b、事件表。事件表的属性包括订单的操作时间、原始状态、操作后的状态、操作人员以及操作时间。如下表 4.4 所示。 c、超时表。超时表用于记录订单的超时时间点、超时时长、超时环节等属性。如下表 4.5 所示。 同时结合其他成员对该模块中其他表的设计得出，订单管理模块的 E.R 图如此图 4.11 所示： 从 E-R 图中能够直观的看出各实体间的关联关系。门店和订单之间是 1 对多的关系，将门店表的主键门店序号存入订单表中；客户和订单是 1 对多的关系，将客户的主键客户序号存入

15、到订单表中。订单和超时是 1 对多的关系，将订单的主键订单序号存入到超时表中。订单和事件是 1 对多的关系，将订单的主键订单序号存入到事件表中。能够得出相关表的新增属性。 3客服管理模块数据库设计。 通过需求分析能够总结出，该模块共牵涉订单表、服务区域表，用户表和用户地址表等六张表，订单表与订单管理模块产生了数据穿插，在这里不再赘述。在该模块中，本文作者主要负责服务区域分配区域表的设计。分配区域表主要包括区域名、用户能否可见等属性。如下表 4.6。 通过对业务需求的分析以及结合其他成员在该模块中对其他表的设计得出，客服管理模块的 E-R 图如以下图 4.12 所示： 从 E-R 图中能够直观的

16、看出各实体间的关联关系。员工和角色之间是多对多的关系，为了遵循数据库设计的可扩展性和规范化，选择新建一张员工和角色的关联表-员工角色表，将员工和角色表的主键；订单和分配区域表是 1 对 1 的关系，将分配区域的主键区域序号序号作存入到订单表中；用户和订单是 1 对 1的关系，选择用户的主键用户序号参加到订单表；订单和地址是 1 对 1 的关系，将地址表中的主键地址序号参加到订单表中；由此得出相关表的新增的属性。 2、微信端数据库表设计。 通过 4.2.2 节中微信端功能的划分发现，用户表主要负责存储用户的基本属性，用户通过手机号登录，因而，属性中应包含手机号，且唯一。用户的来源包括几个方面：通

17、过运营后台充值注册、微信端注册等，因而，增加一列用户来源列。还包括注册时的密码、账户余额以及能否为商户。用户表如下表 4.7 所示。 使用微信支付给余额充值时，余额日志表会发生变化，因而，牵涉用户余额日志表，如表 4.8 所示，记录用户余额的变化，包括原始余额、操作后余额等。 使用微信支付给订单付款，牵涉到订单表、用户表，同时订单付款成功，订单状态发生变化，生成订单操作事件，因而，牵涉事件表。这三张表在前面部分已经完成设计，在这里不做赘述。微信端部分 E-R 图如此图 4.13 所示。 平台中由其他成员负责的表设计亦是如此，经过对所有的表进行设计之后，得到平台中表之间的关系模型如此图 4.14 所示： 4.4 本章小结。 本章根据需求分析，对平台进行架构设计，功能划分和数据库设计。在架构设计方面，阐述了分层架构设计。在功能划分部分，描绘叙述了运营端和微信端中由本文作者负责的功能设计。在数据库设计方面，主要描绘叙述了用户表、订单表等 10余张表的设计。以上三方面设计为平台的实现打下了良好的基础。