当前位置: > 财经>正文

软件工程课程实践 黄金基金怎么算盈亏情况的数据分析报告表格图片

2023-07-29 12:59:48 互联网 未知 财经

软件工程课程实践

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功能分配

 

序号

功能

功能说明

备注

1

用户注册

用户可以在注册界面,通过表单验证注册个人的用户账号

2

用户登录

用户使用注册的账号进行用户的登录操作

3

用户信息的展示与修改

在用户管理功能模块,用户可以看到数据库已有的用户的相关信息,并且可以编辑个人的信息

4

用户安全管理

这里完善的安全中心,我们可以通过原密码修改密码,邮箱修改密码,设置密保问题,通过密保问题修改密码

5

用户注销登录

这里可以注销我们的账号,切换别的账号。

6

每日基金查询功能

我们可以通过基金代码进行精确地查询,查看基金的各项指标

7

每日基金排序功能

我们这里加入了基金的表格的排序功能,我们可以根据各个字段进行排序

8

每日基金购买功能

用户的基金购买,在我们选中我们想要购买的基金后,我们购买相应的份额。

9

过往基金的按日查询功能

我们可以选择过往的日期,查询当天所有基金的各个字段的状况

10

过往基金的按类查询功能

我们可以输入基金的代码,查询该基金直至今日的所有情况

11

过往基金的简称查询功能

我们可以输入基金的简称,查询该基金直至今日的所有情况

12

基金查询的所有功能的图标展示

以上三种过往基金信息的查询,我们加入了可视化图表的方式,方便用户观察和对比

13

基金管理的抛售功能

在该模块我们可以进行基金的抛售,我们可以根据盈利情况进行基金的抛售,选择抛售的份额,这里我们对用户份额的抛售进行了限制,如不可超过已拥有的份额,不可为小数或者非正数。

14

基金管理的查询功能

用户可以查询自己所拥有的某一种基金的情况

15

购买记录功能

在该模块我们加入用户功能记录的记录功能,方便用户查询

16

抛售记录

这里我们可以看到我们抛售的记录,其抛售时间精切到分秒,也可以看到我们抛售的份额,抛售时的净值以及盈利情况。

17

基金统计的图标分析

这里我们结合可视化图形的形式,进行数据的展示,这里我们分为三张图表,基金统计表,通过饼状图的展示,我们可以看到各项基金份额占比。盈利统计表,这里我们可以看到已盈亏,持仓盈亏,总盈亏的各项数据对比与展示。收支统计表,这里我们可以看到我们已收入,待收入,总收入,总支出等数据的显示和对比。

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  基金市场表

属性

字段名

数据类型

可否为空

基金代码

stock_id,

varchar(255)

PK

N

日期

date

date

PK

N

基金简称

stock_name

varchar(255)

N

单位净值

nav

double 

N

日增长率

day_growth

double

(2)投资者表(用户ID号,邮箱,性别,电话,年龄,密码,昵称,属性,血型)

命名规范::user(id,email,nickname,sex,phone,age,password,zodiac,blood_type)。

关系描述:(表5-2-2)。

表5-2-2投资者表

属性

字段名

数据类型

可否为空

用户ID号

id

Int

PK

N

邮箱

email

varchar(50)

N

昵称

nickname

varchar(50)

N

密码

password

varchar(19)

N

电话

phone

varchar(30)

Y

年龄

age

varchar(50)

Y

性别

sex

int

Y

属性

zodiac

varchar(50)

Y

血型

blood_type

varchar(3)

Y

(3)个人基金表(编号,用户ID号,拥有时间,基金代码,基金名称,拥有时净值,拥有份额)

命名规范:stock_have(id,date,stock_id,stock_name,user_id,nav,amount)。

关系描述:(表5-2-3)。

表5-2-3  个人基金表

属性

字段名

数据类型

可否为空

编号

id

int

PK

N

用户ID号

user_id

int 

FK

N

拥有时间

have_time

date 

N

基金代码

stock_id

varchar(255)

FK

N

基金名称

stock_name

varchar(255)

 FK

N

拥有时净值

have_nav

double

 FK

N

拥有份额

amount

int

N

(4)购入交易表(编号,用户ID号,基金代码,购入时间,购入净值,购入份额)。

命名规范:buy_record(id,date,stock_id,stock_name,user_id,nav,amount)。

关系描述:(表5-2-4)。

表5-2-4  员工基本信息表

属性

字段名

数据类型

可否为空

编号

id

int

PK

N

用户ID号

user_id

int 

FK

N

拥有时间

have_time

datetime

N

基金代码

stock_id

varchar(255)

FK

N

基金名称

stock_name

varchar(255)

 FK

N

拥有时净值

have_nav

double

 FK

N

拥有份额

amount

int

N

(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  用户信息表

属性

字段名

数据类型

可否为空

编号

id

int

PK

N

用户ID号

user_id

int 

FK

N

拥有时间

have_time

date

N

基金代码

stock_id

varchar(255)

FK

N

基金名称

stock_name

varchar(255)

 FK

N

拥有时净值

have_nav

double

 FK

N

抛售时间

date

datetime

N

抛售净值

nav

double

FK

N

抛售份额

amount

int

N

盈利

profit

double

N

5.3 E-R实体关系图

  E-R图图例如图5-3-1所示。

 

 

图5-3-1 E-R图图例

系统的E-R图,如图5-3-2所示。

 

 

图5-3-2 系统E-R图

5.4 数据结构与程序的关系

 

用户端在系统的使用过程中会对数据库的中的数据进行“增删改查”等操作,为了方便后端与数据库的交互以及后端各个模块之间的交互,我们对我们使用到数据结构进行了封装,把这些对象都封装成了类,存放在我们后端“pojo”包中,方便我们进行数据的传输。

6. 性能设计

6.1处理能力

由于是在线系统,其处理能力主要考虑系统能承载的最大并发用户数,按照实际情况的规划,系统至少能承载的最大并发用户数要求达到50000人次,随服务器容量而定。

型互联网系统的挑战主要包括:高并发和大流量请求的挑战,高可用的挑战,海量数据的挑战,网络情况复杂、安全性差的挑战,以及需求快速变更、发布频繁的挑战。为了应对这样的挑战,需要提升系统的处理能力。处理能力提升有两种手段,一种是垂直伸缩,一种是水平伸缩。垂直伸缩有自身的局限性,所以在互联网企业中主要使用的手段是水平伸缩。

水平伸缩的原理就是不断地增加服务器以提高系统的处理能力。而如何添加新服务器,使新的服务器和原有的服务器构成一个完整的整体对外提供服务,就是互联网架构的主要技术挑战和技术内容。

在应对挑战的过程中,互联网架构主要的应对方法,就是从单机系统到分布式系统。即通过服务器拆分的方式,系统架构从单机系统一个服务器变成很多个服务器。这是整个发展思路以及发展过程。

其中最主要的发展阶段包括:

使用分布式的缓存,提高系统的访问特性,减少数据存储的压力;

使用负载均衡,提供

版权声明: 本站仅提供信息存储空间服务,旨在传递更多信息,不拥有所有权,不承担相关法律责任,不代表本网赞同其观点和对其真实性负责。如因作品内容、版权和其它问题需要同本网联系的,请发送邮件至 举报,一经查实,本站将立刻删除。