第五次作业——软件设计
Posted ylem10
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第五次作业——软件设计相关的知识,希望对你有一定的参考价值。
第五次作业——软件设计
在开始软件设计之前,首先确定软件设计中的各个模块需要考虑的任务,绘制概要图如下:
下面根据上述各个模块,逐层进行软件设计:
一、概要设计
首先,概要设计的目的是确定软件的结构以及各组成成分(子系统或模块)之间的相互关系,这样,意味着需要确定我们平台的总体实现方案,这个实现方案由于需从软件各模块进行考虑,因此我们在设计过程中选择由数据流图入手,各组分逐一分析。
除此之外,在概要设计部分,我们要大致确定平台所使用数据库的表、约束以及表之间的联系,这个设计决定了之后系统各模块能够达到的耦合、内聚程度。
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 以上是关于第五次作业——软件设计的主要内容,如果未能解决你的问题,请参考以下文章