1．引言
1.1编写目的
在本基金管理系统项目的前一阶段，也就是需求分析阶段中，已经将系统用户对本系统的需求做了详细的阐述，这些用户需求已经在上一阶段中对基金市场和基金用户的实地调研中获得，并在需求规格说明书中得到详尽得叙述及阐明。
本阶段已在系统的需求分析的基础上，对基金管理系统做概要设计。主要解决了实现该系统需求的程序模块设计问题。包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。在以下的概要设计报告中将对在本阶段中对系统所做的所有概要设计进行详细的说明。
在下一阶段的详细设计中，程序设计员可参考此概要设计报告，在概要设计对基金管理系统所做的模块结构设计的基础上，对系统进行详细设计。在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改时找出在本阶段设计的不足或错误。
1.2项目背景
必须在保证各硬件设备．软件系统齐备的情况下，资金充足，人员齐备，各方面互相配合，齐心协力，共同完成。
1.3定义
1.3.1 专门术语
SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。
SQL: 一种用于访问查询数据库的语言
事务流：数据进入模块后可能有多种路径进行处理。
主键：数据库表中的关键域。值互不相同。
外部主键：数据库表中与其他表主键关联的域。
ROLLBACK: 数据库的错误恢复机制。
1.3.2 缩写
系统：若未特别指出，统指本机票预定系统。
SQL: Structured Query Language（结构化查询语言）。
ATM: Asynchronous Transfer Mode (异步传输模式)。
1.4参考资料
以下列出在概要设计过程中所使用到的有关资料：
1.《基金管理系统项目计划任务书》 软件开发小组
2．《基金管理系统项目开发计划》 软件开发小组
3．《需求规格说明书》 软件开发小组
6．《软件工程》 张海藩 清华大学出版社
7．《软件工程》 钱乐秋 清华大学出版社
2．任务概述
2.1目标
2.2运行环境
系统将由两部分程序组成，用户网络设备浏览器前端及基金管理系统的数据服务器程序。
根据调研得知现在市场上常用的浏览器，比如Edge、Chrome、Firefox等都能够满足用户的访问需求
2.3需求概述
随着当今社会的快速发展，人们的生活日益美好。在吃穿无忧的情况下，人们逐渐注重个人理财，其中基金就是理财产品的一种。基金的收益平稳，风险较低，受到了大多数人的青睐，但是大部分的消费者并不懂专业数据管理与分析，对个人基金也没有合理的规划。本系统的开发由此而来，用于解决基金用户日常的基金管理和数据分析，让用户可以合理规划自己的基金。
要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求浏览器前端的界面要简单明了，易于操作，服务器程序利于维护。
3．总体设计
3.1数据流图
顶层数据流图0层数据流图1 层数据流图3.2总体结构和模块外部设计
3.3功能分配
4．接口设计
4.1外部接口
4.1.1 用户界面
在用户界面部分，根据需求分析的结果，用户需要一个用户友善界面。在界面设计上，应做到简单明了，易于操作，并且要注意到界面的布局，应突出的显示重要以及出错信息。我们系统采用的是B/S结构，其中浏览器端可以在移动设备和电脑网页上使用，为了提供一个精美友好的界面，我们采用了Semantic UI的前端界面框架，相比于其他框架，它的优势在于对于移动端页面和客户端页面的响应式布局，以及强大的UI组件库等。在页面组件设计上，它的组件灵活生动，不那么直板僵硬，冗余度和创造性较高。Semantic作为一款开发框架，它能够帮助开发者使用对人类友好的HTML语言构建优雅的响应式布局。便于开发和调试，自带简约的可继承系统和主题，可以自由的完成各式各样的元素、集合、视图、模块和行为设计
总的来说，系统的用户界面应作到可靠性、简单性、易学习和使用
4.1.2 软件接口
主体框架使用spring boot+MyBatis-plus,数据库使用MySQL，使用REST风格接口。REST风格就是使用不同的请求方式完成不同的功能。
客户端通过访问接口发出请求，然后tomcat转给我们的后端controller，controller再调用service里的业务逻辑，service再调用dao层进行一系列的处理，最后将结果返回给用户，我们在dao层使用Mybatis对数据库进行操作。
Spring Boot+Mybatis用来做后端接口开发是非常方便的工具，方便我们实现面向接口编程，这种前后端分离的开发，对于整个项目来说都是非常好的，前端只要关注界面的设计和功能的设计，而后端只要关注数据处理和逻辑的处理，前后端可以并行开发。
4.2内部接口
内部接口方面，各模块之间采用函数调用、参数传递、返回值的方式进行信息传递。具体参数的结构将在下面数据结构设计的内容中说明。接口传递的信息将是以数据结构封装了的数据，以参数传递或返回值的形式在各模块间传输。具体的接口调用过程可以参考上述“4.1.2 软件接口”中的示意图以及文字说明。
数据结构设计
5.1数据库概念结构设计
5.11 实体联系的属性
（1）基金市场（基金代码，日期，基金简称，单位净值，日增长率）
（2）个人基金（编号，拥有时间，基金代码，拥有时净值，拥有份额）
（3）投资者（用户ID号，邮箱，姓名，性别，电话，年龄，密码，昵称，属性，血型）
（4）购入交易（购入时间，购入净值，购入份额）
（5）抛售交易（抛售时间，抛售净值，抛售份额）
（6）拥有（拥有时间）
5.2数据库逻辑结构设计
5.2.1 ER 模型转换为关系模式
我们通过关系1：n和m:n的转化和合并得到如下的关系模式：
（1）基金市场表（基金代码，日期，基金简称，单位净值，日增长率）
PK=（基金代码，日期）
（2）投资者表（用户ID号，邮箱，姓名，性别，电话，年龄，密码，昵称，属性，血型）
PK=（用户ID号）
（3）个人基金表（用户ID号，拥有时间，基金代码，基金名称，拥有时净值，拥有份额）
PK=（用户ID号，拥有时间） FK=（用户ID号，基金代码，拥有时净值）
（4）购入交易表（编号，用户ID号，基金代码，购入时间，购入净值，购入份额）
PK=（编号）FK=（用户ID号，基金代码，购入时间，购入净值）
（5抛售交易表（编号，用户ID号，基金代码，购入时间，购入净值，抛售时间，抛售净值，盈利，抛售份额）。
PK=（编号）FK=（用户ID号，基金代码，抛售时间，抛售净值）
5.2.2 关系模式命名规范和关系模式描述
（1）基金市场表（基金代码，日期，基金简称，单位净值，日增长率）
命名规范：stock(stock_id,date,stock_name,nav,day_growth)
关系描述：（表5-2-1）。
表5-2-1基金市场表
（2）投资者表（用户ID号，邮箱，性别，电话，年龄，密码，昵称，属性，血型）
命名规范:：user(id,email,nickname,sex,phone,age,password,zodiac,blood_type)。
关系描述：（表5-2-2）。
表5-2-2投资者表
（3）个人基金表（编号，用户ID号，拥有时间，基金代码，基金名称，拥有时净值，拥有份额）
命名规范：stock_have(id,date,stock_id,stock_name,user_id,nav,amount)。
关系描述：（表5-2-3）。
表5-2-3个人基金表
（4）购入交易表（编号，用户ID号，基金代码，购入时间，购入净值，购入份额）。
命名规范：buy_record(id,date,stock_id,stock_name,user_id,nav,amount)。
关系描述：（表5-2-4）。
表5-2-4员工基本信息表
（5）抛售交易表（编号，用户ID号，基金代码，购入时间，购入净值，抛售时间，抛售净值，盈利，抛售份额）。
命名规范：sell_record(id,date,stock_id,stock_name,user_id,nav,date,buy_date,buy_nav,profit,amount)。
关系描述：（表5-2-5）。
表5-2-5用户信息表
5.3 E-R实体关系图
E-R图图例如图5-3-1所示。
图5-3-1E-R图图例
系统的E-R图，如图5-3-2所示。
图5-3-2系统E-R图
5.4 数据结构与程序的关系
用户端在系统的使用过程中会对数据库的中的数据进行“增删改查”等操作，为了方便后端与数据库的交互以及后端各个模块之间的交互，我们对我们使用到数据结构进行了封装，把这些对象都封装成了类，存放在我们后端“pojo”包中，方便我们进行数据的传输。
6. 性能设计
6.1处理能力
由于是在线系统，其处理能力主要考虑系统能承载的最大并发用户数，按照实际情况的规划，系统至少能承载的最大并发用户数要求达到50000人次，随服务器容量而定。
型互联网系统的挑战主要包括：高并发和大流量请求的挑战，高可用的挑战，海量数据的挑战，网络情况复杂、安全性差的挑战，以及需求快速变更、发布频繁的挑战。为了应对这样的挑战，需要提升系统的处理能力。处理能力提升有两种手段，一种是垂直伸缩，一种是水平伸缩。垂直伸缩有自身的局限性，所以在互联网企业中主要使用的手段是水平伸缩。
水平伸缩的原理就是不断地增加服务器以提高系统的处理能力。而如何添加新服务器，使新的服务器和原有的服务器构成一个完整的整体对外提供服务，就是互联网架构的主要技术挑战和技术内容。
在应对挑战的过程中，互联网架构主要的应对方法，就是从单机系统到分布式系统。即通过服务器拆分的方式，系统架构从单机系统一个服务器变成很多个服务器。这是整个发展思路以及发展过程。
其中最主要的发展阶段包括：
使用分布式的缓存，提高系统的访问特性，减少数据存储的压力；
使用负载均衡，提供更多的应用服务器提高系统计算处理能力；
使用分布式存储，提供更多的服务器，分摊数据的读写压力；
使用微服务与异步架构，使系统变得更加低耦合，使应用业务变得更加可复用，提升业务处理能力，从而支撑起一个大型网站系统架构。
6.2响应时间
为了能够快捷地提供在线系统服务，系统应该能够快速地响应在线请求。用户最终得到结果的响应时间除了与系统响应速度有关外，还与网络状况有关。因此对移动端网络有较高的需求。
响应时间是一个计算机，显示器成像等多个领域的概念，在网络上，指从空载到负载发生一个步进值的变化时，传感器的响应时间。通常定义为测试量变化一个步进值后，传感器达到最终数值90%所需要的时间。网络对整体响应时间的影响是通过不同机制完成的。在图像领域的液晶显示器响应时间，是液晶显示器各像素点对输入信号反应的速度，即像素由暗转亮或由亮转暗所需要的时间（其原理是在液晶分子内施加电压，使液晶分子扭转与回复）。常说的25ms、16ms就是指的这个反应时间，反应时间越短则使用者在看动态画面时越不会有尾影拖曳的感觉。一般将反应时间分为两个部分：上升时间(Rise time)和下降时间(Fall time)，而表示时以两者之和为准。
6.3数据库性能
建立一个高效冗余度好的数据库，一方面能更好的满足和服务用户，另一方面能以较小的损坏度把数据存放在其中。因此，在设计数据库时要满足以下几个原则：
(1)规范化原则。数据库的新建必须合理规范，以便数据库有较好的冗余。
(2)完整性原则。使存放在数据库中数据有很高的正确性，不能遭受破坏。对输入的数据进行审核和约束。
(3)一致性原则。事务结束后，数据必须保持统一步调。
(4)安全性原则。对数据库的访问者进行安全验证，避免没有权限的访问者对数据库进行访问和有权限的访问者无访问数据库。
根据当前计算机硬件的基本性能指标及其在数据库中主要操作内容，可以整理出如下图所示的性能基本优化法则：
1、减少数据访问（减少磁盘访问）
2、返回更少数据（减少网络传输或磁盘访问）
3、减少交互次数（减少网络传输）
4、减少服务器CPU开销（减少CPU及内存开销）
5、利用更多资源（增加资源）
6.4 安全性设计
与Intemet连接，网络系统可能面临以下威胁：非法访问等。风险分析安全及防护意识的不足，可能导致危害入侵别的系统，造成网络大面积出现故障那一运行甚至可能造成重大损失。网络安全风险主要有链路传输风险、内部局域网的安全威胁、公网互联安全威胁等。
1）系统安全分析
当前很多的系统，都存在已发现及未发现的漏洞。通过对系统以及服务器进行适当的安全性配置，可以降低这方面的风险。另外，对于官方发布的系统安全补丁，应在第一时间进行补漏，这样可以修复最新漏洞，在一定程度上可以提高系统的安全性。
2)应用安全分析
系统的安全包含：邮件的安全、资源共享的安全、数据信息安全、病毒侵害、管理的安全风险等。风险无处不在。我们只能尽可能的降低这种风险所带来的危害，例如架构防火墙或路由，系统合理配置、及时修复漏洞和更新补丁等提高安全防御性。与此同时，制定详细的数据库备份与恢复机制，对数据库进行周期性备份。
7.界面设计
7.1 Semantic UI前端框架
Semantic作为一款开发框架，它能够帮助开发者使用对人类友好的HTML语言构建优雅的响应式布局。便于开发和调试，自带简约的可继承系统和主题，可以自由的完成各式各样的元素、集合、视图、模块和行为设计
7.2前端布局设计
登录界面设计注册界面设计主界面设计安全管理界面设计基金管理界面设计8.安全保密设计
对于用户的私密信息进行安全的加密，对于后端维护人员不可见，比如我们对用户的密码进行不可逆的md5哈希加密，对用户的账户进行保护
