智慧教育产品开发方案.docx

1、智慧教育产品开发方案（正本）智慧教育产品 第一阶段开发方案2019年2月12日1. 引言1.1. 目的 为了让用户和软件开发者双方对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础，特编写本需求。本文档主要对业务需求进行细致描述，明确业务处理范围，并对要实现的功能、输入输出数据和性能要求进行说明，力求准确、清晰、完整地阐明用户的需求，是进行需求分析的基础。本文档预期读者： 需求提出方，银校联盟市场人员 参与需求分析、开发测试的人员1.2. 背景 需求提出者需求完整名称：银校联盟项目第一阶段需求整理需求提出部门：2. 需求目标2.1. 用户描述填写说明：本部分内容描述需求涉及的用户和角

2、色。该部分内容为必填。银校联盟主要涉及以下用户和角色： 银行 校园联盟运营方 学校（培训机构） 商家（入驻） 消费群体2.2. 业务价值填写说明：描述需求中相关角色所关心的业务价值，建立业务价值与业务目标的关联。该部分内容为必填。1、打通消费群体与学校、商家之间的连接关系，通过银校一账通延伸消费场景；2、通过银校联盟运营，向更多的机构、消费群体推广，提高运营方整体利润；3、建立围绕学生教育培训的垂直电商平台，向培训上下游产业链扩张；4、建立学校、商家宣传平台，更好地推广其课程和服务。3. 需求范围3.1. 功能范围本需求涉及的功能范围主要包括用户端和后台管理端两大功能体系。用户端功能主要面向消

3、费者，包括：账户中心、账户充值（微信）、礼券兑换、钱包管理、商家宣传、学校简介、线下支付、在线客服等功能。 账户充值：用户可通过微信对账户进行充值，用户充值完成后，可通过账户查看充值记录； 账户管理：用户可以浏览查看账户历次充值记录、消费记录、账户流水等信息； 礼券兑换：由平台方设置相对应的营销策略，用户充值成功后可购买相应的礼券用于销费； 礼券管理：用户可以浏览查看礼券兑换记录、消费记录、礼券余额等信息； 账户中心：用于记录用户的基本信息、补充信息、学习信息、历交充值记录、消费记录、礼券使用情况等信息。 商家宣传：用于展示入驻平台的商家的基本信息，商家所提供的产品信息、联系地址等信息； 学校

4、简介：用于展示入驻平台的学校、培训机构的基本信息，课程信息，培训内容、联系地址等信息。 在线客服：用于在线与用户沟通，商品答疑，售后服务等；后台管理端功能主要面向平台运营方、商家、学校（培训机构）等，主要包括：商家管理、学校（培训机构）管理、支付管理、营销策略、消费者管理、结算管理、在线沟通、统计报表等功能； 商家管理：主要用于平台方对商家账号的管理，商家发布信息的审核、真实性确认等； 学校（培训机构）管理：主要用于平台方对学校（培训机构）的管理，对其发布信息的审核、真实性确认等； 支付管理：记录用户的充值记录、充值流水、消费记录，当前账户情况等信息； 营销策略：用于设置现金与礼券营销策略，兑

5、换情况，礼券使用限制、生效限制、使用说明等信息； 消费者管理：用于收集用于消费者信息，便于后续营销推广； 在线沟通：用于在线回答用户所提疑问、售后咨询等。 结算管理：用于平台方与商家、学校间进行支付结算使用，包括：交易流水、交易频率、交易周期等信息； 商家和学校（培训机构）用户，主要用于发布基本信息、所提供服务内容资料的管理，用户消费记录，结算账户金额等信息。 统计报表：用于记录平台运营数据的统计分析、报表生成等。3.2. 关键业务流程 充值业务流程银行入账清算充值成功，入账充值失败，提示个人账户交易清算，生成交易码线下交易平台交易清算通过平台购买培训服务、商品消费者个人账户入账 支付业务流程

6、4. 项目规划4.1. 技术框架4.2. 研发计划4.3. 资源配置5. 参考技术线路平台支持微服务架构，可由一个或多个微服务组成。平台中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。平台要支持组件化、松耦合、服务自治、去中心化、容错处理、易扩展、监控、支持不同的开发语言、独立部署等。5.1. 分布式架构分布式系统（distributed system）是建立在网络之上的软件系统。在分布式数据系统中，用户感觉不数据是分布的，即用户不须知道关系是否分割，有无副本，数据存在于那个站点以及事物在哪个站点上执行。简单来说：在一个分布式系统中，一组

7、独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。分布式系统作为一个整体对用户提供服务，而整个系统的内部的协作对用户来说是透明的，用户就像是指使用一个mysql一样。如：分布式mysql中间件mycat ,来处理大并发大数据量的构架。5.2. RESTful架构RESTful是一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 RE

8、ST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。5.3. SOA架构SOA (Service-Oriented Architecture)，面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、

9、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA 是一个组件模型， 它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。 5.4. Web Service技术Web Service是解决程序之间互相通信的一项技术。严格地说，Web Service是描述一系列操作的接口。它使用标准的、规范的XML描述接口。这一描述中包括与服务进

10、行交换所需要的全部细节，包括消息格式、传输协议和服务位置。而在对外的接口中隐藏了服务实现的细节，仅提供一些列可执行的操作，这些操作独立于软、硬件平台和编写服务所用的编程语言。Web Service模型的解决方案中共有3种工作角色，包括服务提供者、服务请求者和服务注册中心。它们之间的交互和操作构成了 Web Service的体系结构。服务提供者定义并实现Web Service，然后将服务描述发布到服务请求者或服务注册中心;服务请求者使用查找操作从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用Web Service。Web Service模型的3种角色及它们之间的操作关

11、系。要实现互操作性，Web Service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。目前这些协议有：SOAP：即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，但XML有效负载保持

12、相同。Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。WSDL：Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。UDDI： UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发

13、现的访问协议的实现标准。5.5. JSON技术 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于JavaScript（Standard ECMA-262 3rd Edition - December 1999）的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C+, C#, Java, JavaScript, Perl, Python等）。这些特性使JSON成为理想的数据交换语言。 JSON较XML更方便于传输，较少冗余的字符。 JSON方便转换。有很多的json api提供了json字符串转成对象、对象转换成json串的方法。 JSON易于阅读。json代码的良好结构，可以很直观地了解存的是什么内容。