第五次作业——软件设计

第五次作业——软件设计

在开始软件设计之前,首先确定软件设计中的各个模块需要考虑的任务,绘制概要图如下:

 

 

 

下面根据上述各个模块,逐层进行软件设计:

 

一、概要设计

 

  首先,概要设计的目的是确定软件的结构以及各组成成分(子系统或模块)之间的相互关系,这样,意味着需要确定我们平台的总体实现方案,这个实现方案由于需从软件各模块进行考虑,因此我们在设计过程中选择由数据流图入手,各组分逐一分析。

  除此之外,在概要设计部分,我们要大致确定平台所使用数据库的表、约束以及表之间的联系,这个设计决定了之后系统各模块能够达到的耦合、内聚程度。

 

1.1 数据流图

  由在需求分析中所确定的针对不同用户的产品功能性的需求分析,绘制平台数据流图如下:

 

  ①平台顶层数据流图

 

 

  在绘制完平台顶层数据流图以后,针对平台各个模块绘制1级数据流图如下:

 

  ② 论坛模块

   

  ③平台基本功能模块

 

 

  ④ 数据分析模块

 

 

1.1.1 平台的总体实现方案

 

  在绘制数据流图以后,我们通过理解各个模块的数据输入输出流,即可对整个平台的实现有总体的规划,确定总体的实现方案,我们准备从如下三个模块入手:

 

1.1.1.1 组成系统的物理元素清单

总体元素

作用与功能

数据库

是平台的基础,反映了平台的设计结构

 

数据分析接口

是完成平台数据处理功能的模块

 

 

总体平台

包括主页面、数据分析页面、用户管理页面、论坛区、用户反馈页面等。整个项目的功能以平台为载体来实现。

 

1.1.1.2 实现进度计划

  关于这部分,在上次的作业中我们已经大致规划过了,但由于还未对整个项目进行上述那样详细的功能分析与设计,部分设想需要进行适当修改,结合上面的分析对其进行修改如下:

 

分工

负责人

实现方式

前端

纪芳 & 廖文静

HTML + CSS5 + JAVASCRIPT

 

后台

林光涵 & 林瑞溶(辅助)

PYTHON + MYSQL

 

数据库

张泽政 & 林瑞溶 

MYSQL

 

算法接口

刘涛 & 张泽政 (辅助)

 

 

 

时间

负责人

负责任务

 

 

 

 

第11-12周

刘涛、张泽政

完成对项目的配置,确定数据分析的主要实现方式。

 

林光涵、林瑞溶

学习Python,对过程中已经写好的页面与数据库进行前后台对接。

 

纪芳、廖文静

前端页面的编写。

 

张泽政、林瑞溶

对数据库进行全面的建立,并根据实际情况对数据库进行修改与重构。

 

 

 

 

 

第13周

刘涛、张泽政

实现数据分析接口,并进行数据分析的优化。

林光涵、林瑞溶

对后台的逻辑进行补充设计,完善平台功能。

纪芳、廖文静

对前端页面细节进行优化。

 

 

 

 

 

 

第14周

 

 

小组全体成员

对基本成型的平台进行审核,平台测试,并发现遇到的问题,及时进行修正、改进。采取调查的方式让其他人体验平台,获取他人意见并进行改进。

 

1.1.1.3 系统流程图(HIPO图)

 

 

1.2数据库逻辑结构设计

1.2.1 建表

数据库初步建表如下:

表  名

作  用

用户信息表

table_user_info

    存储用户的基本信息

 

 

 

 

用户权限表

 

 

 

 

table_user_rights

记录用户的权限,如普通用户、管理员。

单独列一张表而不是把表分为用户表和管理员表的理由:

① 普通用户和管理员有很多相同的属性,这样可以节省空间。

② 最主要的原因,管理员可以修改用户信息,假如分为两张表,就意味着管理员可以随意修改用户的权限。

 

操作记录表

 

table_op_record

    记录用户在平台的操作以及所使用的数据存放路径,如上传数据、分析数据等,用户进行分析的数据将自动保存,只保存最近的5次操作。

 

反馈信息表

 

table_feedback

用户向平台提出意见,由管理员来接收,管理员根据意见选择性的回应,回应消息由用户接收。

发贴表

table_poster

    参考自博客园的博客存放形式,把帖子的内容存放到数据库里。

图片存放表

table_picture

    记录用户评论、发帖时使用的图片路径。

评论表

table_comment

    用户对某个帖子的回复信息。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 




1.2.2确定各字段的约束条件

  在这部分中,我们首先要确定每个表具有哪些字段, 在确定时还可以顺便完成一步我们在物理设计时完成的任务:确定每个字段的类型,如整数,char等,对于char类型要格外注意,既不能把长度开的太大,导致空间的浪费,也不能开的太小,导致部分数据丢失。

表名:table_user_info

别名:用户信息表

描述:存放用户的基本信息。

 

中文

列名

数据类型

约束条件

描述

用户名

user_login_name

char(25)

PK

唯一标识某个用户。

 

用户密码

 

user_pwd

char(15)

Not Null,

Check(长度≥6 &

不能为纯数字)

 

用户的密码,非空.

check约束由触发器实现。

用户昵称

user_Nick_name

char(20)

Default.

用户的昵称,在注册时若未指定,使用触发器生成默认值。

用户手机号

user_phone

Vachar(11)

Unique

因为可以通过手机快捷注册,所以该列必须加unique约束。

用户邮箱

user_Email

char(25)

-

服务器脚本检验邮箱的合法性。

 

表名:table_user_rights

别名:用户权限表。

描述:记录用户的权限,如普通用户、管理员。

 

中文

列名

数据类型

约束条件

描述

用户名

user_login_name

char(25)

PK,FK

唯一标识某个用户,外键关联自用户信息表。

 

用户身份

 

user_status

char(15)

 

Not Null

 

用户的权限。

 

表名:table_op_record

别名:操作记录表

描述:记录用户在平台的操作以及所使用的数据存放路径,用户在平台进行操作(保存数据,数据分析)时,平台自动保存用户使用的数据并生成相应记录。

中文

列名

数据类型

约束条件

描述

操作时间

opt_time

datetime

PK

产生操作的时间。

 

用户名

 

user_login_name

char(25)

 

FK,PK

唯一标识某个用户,外键关联自用户信息表。

操作类型

opt_type

char(20)

Not Null

操作的类型(如保存数据、数据分析)。

 

数据存放路径

 

opt_data_route

 

char(50)

 

-

因为用户使用的数据量会非常大,因此不宜保存在数据库中,这里保存方法是保存在文件中,由数据库指向其存放路径。

 

表名:table_feedback

别名:反馈表

描述:用户向平台提出意见,由管理员来接收,管理员根据意见选择性的回应,回应消息由用户接收。

中文

列名

数据类型

约束条件

描述

消息接收时间

fbk_receive_time

datetime

PK

产生操作的时间。

 

发送者用户名

 

fbk_sender

 

char(25)

 

FK,PK

唯一标识消息的发送者,外键关联自用户信息表。

 接收者用户名

fbk_recipient

char(25)

FK,PK

唯一标识消息的接收者,外键关联自用户信息表。

消息类型

fbk_info_type

char(25)

Not Null

发送消息的类型,如用户反馈、管理员回复等。

 

消息内容

 

fbk_info_content

 

varchar(255)

 

 

-

消息的内容,一般一条反馈消息不会太长,默认255个字符足够,而考虑到有些特殊情况,这里采用边长的varchar类型,可以根据实际来调整大小。

 

表名:table_poster

别名:发帖表

描述:参考自博客园的博客存放形式,把帖子的内容存放到数据库里。

中文

列名

数据类型

约束条件

描述

 

帖子ID

 

post_id

 

varchar(60)

 

PK

帖子的ID,该属性是为了方便的标识某个帖子,由用户名和发帖时间拼接生成(保证唯一性),生成操作由触发器实现。

 

发贴者用户名

 

fbk_sender

 

char(25)

 

FK

唯一标识发帖者,外键关联自用户信息表。

   发帖时间

post_time

datetime

Default

发帖的时间,默认为当前时间

发帖内容

post_content

varchar(5000)

Not Null

参考自百度贴吧的帖子,一个帖子的内容最多5000字符。

 

帖子标题

 

post_title

 

char(80)

 

   Not Null

 

每个帖子应该有一个标题。

帖子类型

post_type

char(20)

Not Null

帖子的类型

 

表名:table_comment

别名:帖子评论表

描述:参考自博客园的博客存放形式,把帖子的内容存放到数据库里。

中文

列名

数据类型

约束条件

描述

 

评论ID

 

comt_id

 

varchar(60)

 

PK

评论的ID,该属性是为了方便的标识某个帖子,由被评论帖子ID和评论时间、评论者用户名拼接生成(保证唯一性),生成操作由触发器实现。

 

发贴者用户名

 

comt_commenter

 

char(25)

 

FK

 

唯一标识评论者,外键关联自用户信息表。

   评论时间

comt_time

datetime

Default

评论的时间,默认为当前时间

被评论贴ID

comt_post_id

varchar(60)

FK

被评论的帖子的ID,外键关联自发帖表。

 

评论内容

 

comt_content

 

varchar(2000)

 

   Not Null

 

参考自百度贴吧,一个回复最多2000字符。

 

表名:table_picture

别名:图片表

描述:记录用户评论、发帖时使用的图片路径。

中文

列名

数据类型

约束条件

描述

 

链接ID

 

pic_id

 

varchar(60)

 

-

图片链接到哪个ID,这个ID指的是帖子的ID或评论的ID,以便加载帖子或评论时读取图片。

 

图片存放路径

 

pic_route

 

char(50)

 

-

一般图片不会直接存放在数据库中,而是存放在物理磁盘上,数据库存放它的路径。

 

1.2.3 确定表之间的关系

表之间的关系最好通过PDM图来表示,如下:

 

二、详细设计

2.1 数据库的物理结构设计

  在“1.2.2确定各字段的约束条件”中,已经完成了物理结构设计中的重要的一部分,即确定每个字段的类型,如整数,char等,对于char类型要格外注意,既不能把长度开的太大,导致空间的浪费,也不能开的太小,导致部分数据丢失。

  在这里,我们进行进一步的物理结构设计: 确定数据库文件的存放路径。

 

物理模型如下:

物理模型

参数

参数值

数据库名

Data_analyze_Project

主文件组

逻辑数据文件名①

PlatForm_Main_1

物理数据文件名①

C:\PlatForm_Main_1.mdf

数据文件的初始大小①

0.5GB

数据文件的最大大小①

Unlimited

数据文件增长帐度①

200MB

逻辑数据文件名②

PlatForm_Main_2

物理数据文件名②

C:\PlatForm_Main_2.ndf

数据文件的初始大小②

0.5GB

数据文件的最大大小②

Unlimited

数据文件增长帐度②

200MB

次要文件组:

逻辑数据文件名①

PlatForm_Minor_1_1

物理数据文件名①

C:\PlatForm_Minor_1_1.ndf

数据文件的初始大小①

600MB

数据文件的最大大小①

Unlimited

数据文件增长帐度①

200MB

 

逻辑数据文件名②

PlatForm_Minor_1_2

物理数据文件名②

C:\PlatForm_Minor_1_2.ndf

数据文件的初始大小②

600MB

数据文件的最大大小②

Unlimited

数据文件增长帐度②

200MB

次要文件组:

逻辑数据文件名①

PlatForm_Minor_2_1

物理数据文件名①

C:\PlatForm_Minor_2_1.ndf

数据文件的初始大小①

2GB

数据文件的最大大小①

Unlimited

数据文件增长帐度①

400MB

 

逻辑数据文件名②

PlatForm_Minor_2_2

物理数据文件名②

C:\PlatForm_Minor_2_2.ndf

数据文件的初始大小②

2GB

数据文件的最大大小②

Unlimited

数据文件增长帐度②

400MB

日志文件

日志逻辑文件名①

PlatForm_Log1

操作系统日志文件名①

C:\PlatForm_Log1.ldf

日志文件初始大小①

0.5GB

日志文件增长幅度①

150MB

 

日志逻辑文件名②

PlatForm_Log2

操作系统日志文件名②

C:\PlatForm_Log2.ldf

日志文件初始大小②

0.5GB

日志文件增长幅度②

150MB

     

 

  对上述参数进行如下解释:主文件组包括两个文件,用于存放数据库的核心信息、数据字典等,这里核心信息指代用户信息。两个次要文件组,第一个次要文件组存放用户的操作信息,第二个次要文件组开的大小比较大,是为了存放比较占空间的贴子以及评论。

现针对具体参数进一步解释:

①主文件组的一个文件用来存放用户信息,一个文件大小为0.5GB,文件增幅为200MB,而对应一个用户的信息大小为 4 + 25 + 20 + 50 = 99B,也就是说 初始情况下,主文件组能存放的用户信息数量约为 0.5GB/99B = 5422938条,而一次文件增长为200MB,能增加的用户信息数量约为 200MB / 99B = 2118335条,这显然是够用的。

②第一个次要文件组存放用户的操作信息,包括两个文件,大小分别为600MB,总大小即为约1.2GB,那么初始情况下,能存放的操作信息为 1.2GB/(4+25+20+50) = 13015052条,两个文件各自一次增长加一起为400MB,能存放的信息数量为:4236670条,显然也是合理的。

③第二个次要文件组开的大小比较大,是为了存放比较占空间的贴子以及评论,包括两个文件,大小分别为2GB,总大小即为4GB,假设平均一个帖子有20条评论,共有20张图片,那么一个帖子的总大小为(60+25+5000+80+20+20*(60+25+60+4+2000)+20*(60+50))=50385B,则初始情况下,能存放的贴数为:4GB/50385B = 85242条,一次增加的大小共为800MB,能存放的信息数量为:16649条,一般情况下应该也是足够的。

 

2.2 系统接口设计

2.2.1 外部接口

在此通过外部接口简述硬件输入输出:

 

 

2.2.2 内部接口

(1)开发模式:采用flask框架结合前端HTML、CSS、JS、Jquery以及mysql组合而成的MVC开发模式。

(2)开发使用的ide: pycharm

(3)MVC模式以及后台目录结构设计

MVC图如下:

 

根据MVC设计的目录结构:

一级目录结构:

  

二级目录结构:

Model层:分为四个模块分别是管理员模块(admin),数据分析模块(dataAnalyze),论坛模块(forum),用户模块(user)

 

View层:

 

Controller层:

 

(4)数据传递方式及代码示例:

View层与Controller层的数据传递

1)view通过超链接的方式给Controller层传递数据

 

2)view通过ajax的方式给Controller层传递数据

 

3)Controller层返回数据给view层

 

 

Model层与Controller层的数据传递

Control层给出参数直接调用Model层中的方法

 

 

2.2.3 神经网络模型接口

①为什么使用神经网络模型?

 

我们用到的数据分析模型是神经网络模型,数学上已经证明,它具有实现任何复杂非线性映射的功能,也就是说这个模型有能力完成从输入数据到输出数据的映射过程。另外在分类问题上,很多研究论文均使用神经网络的方法或者其变形,包括现在很流行的对于图片的分类也采用这种方法的变形,于是我们基于此种趋势,也选择使用神经网络模型分析数据,挖掘数据的内部结构信息。

 

 ②本模型中的神经网络模型的基本原理?

神经网络模型主要是多个神经元相互连接组成的层状结构,结构如下图所示:

 

  

第一层作为数据输入层,此层节点个数等于数据的维度数目;最后一层作为分类层,我们选择是sigmoid作为分类激活函数是因为最后的结果之后两类:0或者1。中间层被称作隐含层,这些层是神经网络能够完成复杂映射的关键。

更加具体的说,我们处理这个问题的整个流程如下图:

 

③模型概述:

本模型的使用包括训练阶段与测试阶段:

训练阶段的流程图为:

测试阶段为:

训练的模型 + 测试数据→→预测结果(概率)

在我们的项目中,网络的结构设置为11,10,1,这些参数是每一层的神经元的数目,除了最后一层采用sigmoid作为激活函数,第一层(数据层)不处理之外,其他的层均采用relu函数进行激活,增加了网络的非线性映射能力。

④实现方式的优点?

在实现神经网络的时候,我们封装了两个类,一个是NNtrainer类,用于数据的训练,一个是NNpredicter类,用于测试数据的预测。在NNtrainer类中,我们实现从数据的读入,训练,模型的存储全过程,可以很轻松的调用其中功能,实现训练过程。NNpredicter也是如此。

 

2.3 软件过程设计及用户接口描述

进行上述详细的分析以后,站在普通用户的角度,对平台的用户过程进行如下图示:

 

 

而管理员用户的操作与用户类似,但是管理员会具有一些特别的权限,如下图:

 

 

posted @ 2017-11-26 16:30  ylemfei  阅读(464)  评论(5编辑  收藏  举报