一、引言
1.1 设计背景
在我们的大学生活中,很容易接收到不完整的通知信息,因为学生基数庞大,信息经过分层传递,当传递到我们这里时很容易产生偏差。尤其是在实验室信息管理这方面,往往有很多重要的信息需要及时向最下级的学生传达,但是仅仅靠分级线上消息传达很难做到尽善尽美。除此之外,学生实验的各种信息(姓名、学号、队伍等)需要一个统一的信息系统收集起来,方便学生自己注册或修改,也方便老师管理人员。而对于不了解教学实验的同学或者其他学校的访客,我们想让他们多了解我们的实验室的环境,设备以及成果,激发同学们的学习兴趣。在这种想法驱使下,我们团队想要设计一个教学实验中心门户来帮助老师实现对于实验室学生信息的管理,帮助学生更加了解实验室,更容易地接受通知,更好的发表自己的观点。本门户网站用于管理实验室,展示实验室相关信息及新闻。用户可以了解实验室设备等基本概况,并进一步了解实验室成果及建设情况。具有管理权限的用户可以对实验室队伍等进行管理。实验室相关信息及新闻将在页面上即时更新,供实验室成员及访客了解实验室最新情况。
1.2 编写目的
我们的目的是让不了解实验室的同学对实验室产生浓厚的兴趣;让实验室的同学能够准确快捷的收到实验室通知;让老师更方便的管理实验室学生;为同学们提供一个展示自己优秀创新成果的平台。
1.3 系统概述
首先,从整体的布局上来说,网站页面布局采用中部导航栏的布局,多版块布局方式,提高页面浏览速度;从外观上采用淡色作为网站的主色调,淡淡的色调让整个页面充满了生气与活力。
其次,网站丰富的内容更是给人耳目一新的感觉,绝美的图片和优美的文字给用户耳目一新的感觉,提供给用户很多要了解的信息。
我们主要想设计的网站包括了首页和 5 大模块:中心概况、实验教学、实验队伍、设备与环境、成果与展示。在首页可以预览到最新的 5 大模块的一定数量的消息,想要专门浏览某一个模块的消息或者想要查看更早的某一模块的消息可以点击进入模块专门查看里面的消息。模块里也按时间排序文章和通知消息,支持翻页查看更早发布的内容。登录注册部分都需要验证码,权限分级可以做不同的事情。
二、开发规划
2.1 开发环境与工具
浏览器 | Chrome |
---|---|
应用服务器 | Tomcat 8.5 |
开发工具 | IntelliJ IDEA 2020.1 x64 |
Java 版本 | Java 8 |
DATABASE | MySQL |
配置管理工具 | Maven |
框架组件 | Spring MVC |
三、开发设计
3.1 需求分析
3.1.1功能需求分析
界面需求分析
功能描述:我们主要想设计一个网页包括了首页和 5 大模块:中心概况、实验教学、实验队伍、设备与环境、成果与展示。在首页可以预览到最新的 5 大模块的一定数量的消息,当然模块可以由管理员增删或修改,如果浏览者想要专门浏览某一消息可以点击模块进入查看。模块里也按时间排序文章和通知消息,支持翻页查看更早发布的内容。
页面流程描述:点击首页搜索查看内容,或点击模块进入模块后查看通知内容。
图示解析:
用户需求分析
-
功能描述:我们设计权限分层,分为管理员,学生和游客,管理员可以对学生账户进行管理,当不登录而浏览网页时身份为游客,初次注册后便可成为学生用户,游客的权限只有浏览文章,搜索文章,而学生可以发表文章。
-
页面流程描述:用户在修改信息的界面输入想要修改的用户的名字,然后更改任何想要修改的信息,点击保存完成修改。
登录/注销/注册需求分析:
- 功能描述:用户可以在本网站注册或登陆自己的账号,可以读取用户输入的信息并保存在数据库或审核信息,并且能够修改自己的密码,管理员可以注销他人账户。
- 页面流程描述:用户提交自己的注册信息,信息汇总到数据库,如果成功则向用户返回注册成功信息。用户输入账号密码,信息汇总到数据库,如果审核通过则成功登录。
- 发布信息功能需求分析
- 功能描述:用户可以在本网站发表文章,其中文字和 word 工作界面类似,可以修改文字颜色,调节文字大小,修改字体,插入图片等。
- 页面流程描述:用户将文字,图片信息存入数据库,点击发布,如果成功则返回发布成功,其他用户可以在网站内查看该信息。
3.1.2非功能需求分析
安全需求分析:
- 性能需求
对页面访问响应时间、查询统计响应时间、并发用户数、在线用户数等进行说明。
- 网络需求
kb/s 及以上的带宽(保证图片可以快速加载)。
- 存储需求
硬盘剩余空间容量与单位个数和每年的项目数大小相关,推荐的 指标为:剩余空间容量 > 基础数据表 300M+ 单位个数 ×100M+ 项目数 ×100M×2 。
-
安全需求
-
权限控制需求根据不同用户,需要设置相应登记管理员权限,等级低的用户不可以修改比自己等级高的用户的信息等,等级最高的用户可以分配修改用户的权限
-
用户自主权需求需要用户可以修改自己的用户信息,发布自己想要发布的内容用户真实性需求我们确保我们每一个用户都是真实的用户,程度上阻止了机器人和闲杂人等注册。 正确返回错误信息需求对于用户的吃错误操作可以返回错误信息告知用户操作错误而不是系统崩溃。
-
运行环境需求
硬件:最低硬件配置要求:内存 512MB,CPU 单核软件: Firefox、Chrome 等浏览器 接口:数据库的配置信息保存在.xml 文件中、对数据库的操作封装在 Operation 类。
3.2网站结构
网页包括首页与六大分模块:中心概况、实验教学、实验队伍、管理模式、设备与环境、成果与展示。首页上会展示最新的四条学校新闻,点击新闻标题或者新闻图片即可进入阅读文章,如果想查看同学或老师发表的文章,可以将页面下拉,首页会展示一部分最新发表的成果展示文章,首页的最下方是实验室的最新通知。点击模块可以查看全部文章,各个模块包含若干子模块,可以点击页面右上导航栏里的模块来进入对应的子模块,各模块文章将按发布日期进行排序,最新发表的文章将在最前面,每页显示 6 篇文章,点击文章标题即可进入阅读。如需进行修改文章等操作,需要先 登录账户,点击右上角的登录和注册按钮进行登录和注册。,注册成功的用户可在登录后点击右上角用户名,进入个人信息页面,所有账户都可以修改自己的信息,点击增加文章可以编辑文章并发布在选定模块,管理员可以修改其他用户信息,管理员的账户信息不能被别人修改。管理员点击增加模块可以在六个固定的顶级模块中增加相应模块。
活动图:
状态图:
组件图:
3.3基本设计框架
3.3.1 物理设计框架
我们以 tomcat8.0 搭建服务器, MySQL 作为数据库支持,使用前后端完全分离开发的框架 MVC,在 controller 控制器部分,使用 Java 语言作为后端开发语言,使用 sevlet 搭建控制层的数据传输 流,利用 Hirbernate 框架实现数据库的增删该查功能。利用 ckeditor 开源文章编辑器实现了编写文章功能。
3.3.2 程序设计框架
图表 1 类图
3.4主要界面描述
3.4.1 注册登录模块
- 功能概述
用户可以在这里注册或登陆自己的账号,修改自己的个人信息、密码等等。
- 业务流程
用户提交自己的注册信息,信息汇总到数据库啊,如果成功则向用户返回注册成功信息
-
对外接口数据库的配置信息保存在.xml 文件中、对数据库的操作封装在 Operation 类中
-
具体实现
-
用户界面
- 时序图
3.4.2 发布信息模块
- 功能概述
用户可以发布自己的文章,其中文字和 word 工作界面类似,可以调节文字大小,修改字体,修改字体颜色,插入图片等等
- 业务流程
用户点击发布将提交的文字、图片等信息存入数据库,如果成功则返回发布成功信息,其他用户可以查看这些信息
- 对外接口
数据库的配置信息保存在.xml 文件中、对数据库的操作封装在 Operation 类中
- 具体实现
- 用户界面
- 时序图
3.4.3 修改信息模块
- 功能概述
用户可以修改自己的个人信息,管理员可以注销账户。
- 业务流程
用户提交所修改的信息存入数据库,如果成功则返回发布成功信息,管理员可以查看这些信息。
- 对外接口
数据库的配置信息保存在.xml 文件中、对数据库的操作封装在 Operation 类中
- 用户界面
- 时序图
3.5其他设计
3.5.1安全性设计
- 权限控制
我们设计管理员,学生分级权限管理,管理员可以修改学生用户信息,也可以注销用户,当发现有人恶意发表文章时,管理员可删除文章并注销该用户。
- 用户个人信息管理
个人用户可以修改自己的个人信息,发布自己想要发布的内容。
- 用户真实性
为确保每一个用户都是真实用户,我们设置了验证码来阻止机器人或闲杂人等注册或登录。
3.5.2用户性能设计
-
操作方便快捷,页面简洁美观,尽量从用户角度出发。
-
提示信息充足,当用户进行某些操作时,系统会给予弹窗提示,以方便用户更直观地完成操作。
4 数据库
4.1数据库的环境说明
4.2 逻辑设计
4.3 物理设计
4.3.1 表汇总
表名 | 功能说明 |
---|---|
account | 用户的信息、权限 |
article | 文章的内容、作者、标题、模块 |
4.3.2表
表的索引: 索引是否建立要根据具体的业务需求来确定。
允许为空:不填的表示为“是”。
唯一:不填的表示为“是”。
表的记录数和增长量:根据具体的业务需求确定。增长量应确定单位时间如果量大可以按每天,如果不大可以按每月。
表字段的区别度:主要是考虑到将来在此字段上建立索引类型选择时作为参考,当字段值唯一时可以不考虑,当字段值不唯一时,估算一个区别度,近似即可。例如:如果一个表的 NAME 字段有共 2000 个值,其中有 1999 个不同值,1999/2000=0.99 越接近 1 区别度越高,反之区别度越低。
表的并发:根据具体的业务需求预测表的并发。
1.
表名 | 表名 | account | account | account | account | account | account |
---|---|---|---|---|---|---|---|
数据库用户 | 数据库用户 | 来访用户 | 来访用户 | 来访用户 | 来访用户 | 来访用户 | 来访用户 |
主键 | 主键 | name | name | name | name | name | name |
其他排序字段 | 其他排序字段 | ||||||
索引字段 | 索引字段 | ||||||
序号 | 字段名称 | 数据类型(精度范围) | 允许为空 Y/N | 唯一 Y/N | 区别度 | 默认值 | 约束条件/说明 |
1 | Name | Varchar(100) | N | Y | |||
2 | id | Bigint(20) | N | N | |||
3 | password | Varchar(100) | N | N | |||
4 | permissions | Bight(20) | Y | N | |||
5 | Varchar(40) | Y | Y | ||||
6 | info | Varchar(40) | Y | Y | |||
7 | status | Varchar(40) | N | Y | |||
MySQL 脚本 | MySQL 脚本 | CREATE TABLE IF NOT EXISTS account(; name VARCHAR(100),; id BIGINT NOT NULL,; password VARCHAR(100) NOT NULL,; permissions BIGINT ,; email VARCHAR(40),; info VARCHAR(40),; status VARCHAR(40),; PRIMARY KEY ( name ); )ENGINE=InnoDB DEFAULT CHARSET=utf8;; | CREATE TABLE IF NOT EXISTS account(; name VARCHAR(100),; id BIGINT NOT NULL,; password VARCHAR(100) NOT NULL,; permissions BIGINT ,; email VARCHAR(40),; info VARCHAR(40),; status VARCHAR(40),; PRIMARY KEY ( name ); )ENGINE=InnoDB DEFAULT CHARSET=utf8;; | CREATE TABLE IF NOT EXISTS account(; name VARCHAR(100),; id BIGINT NOT NULL,; password VARCHAR(100) NOT NULL,; permissions BIGINT ,; email VARCHAR(40),; info VARCHAR(40),; status VARCHAR(40),; PRIMARY KEY ( name ); )ENGINE=InnoDB DEFAULT CHARSET=utf8;; | CREATE TABLE IF NOT EXISTS account(; name VARCHAR(100),; id BIGINT NOT NULL,; password VARCHAR(100) NOT NULL,; permissions BIGINT ,; email VARCHAR(40),; info VARCHAR(40),; status VARCHAR(40),; PRIMARY KEY ( name ); )ENGINE=InnoDB DEFAULT CHARSET=utf8;; | CREATE TABLE IF NOT EXISTS account(; name VARCHAR(100),; id BIGINT NOT NULL,; password VARCHAR(100) NOT NULL,; permissions BIGINT ,; email VARCHAR(40),; info VARCHAR(40),; status VARCHAR(40),; PRIMARY KEY ( name ); )ENGINE=InnoDB DEFAULT CHARSET=utf8;; | CREATE TABLE IF NOT EXISTS account(; name VARCHAR(100),; id BIGINT NOT NULL,; password VARCHAR(100) NOT NULL,; permissions BIGINT ,; email VARCHAR(40),; info VARCHAR(40),; status VARCHAR(40),; PRIMARY KEY ( name ); )ENGINE=InnoDB DEFAULT CHARSET=utf8;; |
记录数 | 记录数 | ||||||
增长量 | 增长量 | ||||||
表的并发 | 表的并发 | ||||||
补充说明 | 补充说明 |
2.
表名 | 表名 | article | article | article | article | article | article |
---|---|---|---|---|---|---|---|
数据库用户 | 数据库用户 | 管理员 | 管理员 | 管理员 | 管理员 | 管理员 | 管理员 |
主键 | 主键 | Id | Id | Id | Id | Id | Id |
其他排序字段 | 其他排序字段 | ||||||
索引字段 | 索引字段 | ||||||
序号 | 字段名称 | 数据类型(精度范围) | 允许为空 Y/N | 唯一 Y/N | 区别度 | 默认值 | 约束条件/说明 |
1 | title | Varchar(100) | N | Y | |||
2 | author | Varchar(100) | N | N | |||
3 | mydate | Bight(20) | N | Y | |||
4 | content | longtext | N | Y | |||
5 | id | Bight(20) | N | Y | |||
MySQL 脚本 | CREATE TABLE IF NOT EXISTS article(; title VARCHAR(100),; author VARCHAR(100) NOT NULL,; mydate BIGINT NOT NULL,; content LONGTEXT NOT NULL,; id BIGINT NOT NULL,; PRIMARY KEY ( id ),; KEY ( mydate )\n; )ENGINE=InnoDB DEFAULT CHARSET=utf8;; | ||||||
记录数 | 记录数 | ||||||
增长量 | 增长量 | ||||||
表的并发 | 表的并发 | ||||||
补充说明 | 补充说明 | ||||||
5 模块设计
5.1 主界面模块设计
5.1.1首页设计图
- 在首页里,我们可以看到最上方的一行导航栏,可以实现到各个页面栏目的跳转。
- 右上角是用户登录/注册或进行账户管理的位置。
- 下方可以进行当前网站中图片的自动播放展示,以及显示一些重要文章的摘要,点击可直接跳转到文章页面。
5.1.2 首页效果图
5.2 登录注册模块设计
5.2.1 注册模块
效果图
5.2.2 登录模块
效果图
5.3 发布信息模块设计
5.3.1 新增/修改/删除文章模块
效果图
5.3.2 查看文章模块
效果图
6 软件测试
6.1测试策略
6.1.1 整体策略
本项目的特点:
- 参与测试的人员都是第一次接触测试系统。
- 项目系统较大,功能模块较多,内容涉及广泛。
- 从开始设计到测试再到项目结束仅有半个多月,时间紧迫。
根据以上特点,制定本项目的测试过程策略如下:
- 短时间内尽可能发现多的缺陷。
- 测试计划、部分用例设计、代码开发同步进行。
- 测试过程受到控制,根据事先定义的测试执行顺序进行测试,并填写测试记录表,保证测试过程是受控且易追溯的。
- 确定重点,测试重点放在网页的功能实现上,在保证了网页功能无缺陷的基础上,尽可能地将页面美观化。
依据标准:
本次测试中测试文档的编写,测试计划的编写,具体的执行测试以及测试中各项资源的分配和估算,都是参照指导老师上课提出的标准进行的。
6.1.2测试范围
要测试的子系统:
测试内容 | 测试范围 |
---|---|
功能测试 | 页面显示模块 |
功能测试 | 文章发布 |
功能测试 | 后台管理 |
功能测试 | 上传图片 |
功能测试 | 账号注册及登录 |
功能测试 | 留言板功能 |
表 1 测试范围
测试通过标准:
- 页面能在不同电脑以及各大常用浏览器上正常显示。
- 文章能成功发布并且可以看到往期发布文章。
- 后台管理无越权操作的漏洞。
- 上传图片成功,文章里正常显示图片。
- 账号注册登录无漏洞,且能较好地管理所有账号。
- 留言板功能无漏洞。
6.1.3 测试类型
- 功能测试
- 性能测试
- 容量测试
- 安全测试
6.1.4 风险分析
测试工程量的风险:
本次我们设计的实验中心门户网站功能繁多,工程量庞大,代码复杂。需要考虑的方面很多,可能有些许功能仅仅是达到预期的目标并不能防范我们想不到的情况所产生的 BUG 或更加严重的情况。
测试人数的风险:
测试人数和时间都非常有限,我们只能在有限的时间内找到尽可能多的 BUG,并不一定能将整个系统做的十全十美。
6.2 测试方法
6.2.1测试用例设计
本次测试的测试案例,是在经过系统培训后,由测试人员根据组内编程人员对系统的介绍和自己对系统的理解按照系统层次结构组织编写。
对于每一个测试用例,测试设计人员应为其指定输入(操作),预期输出(结果)。
- 对每一个测试用例,都必须有详细的测试步骤描述。
- 本次测试设计的所有测试用例均需要以规范的文档方式保存。
- 在整个测试过程中,可以根据项目实际情况对测试用例进行适当地变更。
6.2.2 测试实施过程
本项目由颜小涵作为测试人员负责不同的子系统的测试,实施过程如下:
- 准备测试所需环境。
- 准备测试所需数据。
- 按照系统运行结构执行相应测试用例。
- 记录测试过程和发现的缺陷。
- 记录缺陷并报告。
6.2.3 测试方法综述
本项目测试包括:
- 功能测试,测试各功能是否有缺陷。
- 测试人员执行测试时,要严格按照测试用例中的内容来执行测试工作。
- 测试人员要将测试执行过程记录到测试执行记录文档中。
- 测试人员要对测试中发现的问题记录到缺陷记录中。
6.3 资源需求
6.3.1 软件运行环境
下表列出了被测系统的软件及运行环境。
分类 | 软件 |
---|---|
运行系统 | MacOS、Catalina |
6.3.2 硬件运行环境
下表列出了被测系统的硬件运行环境。
资源类型 | 资源描述 | 资源描述 | 数量 |
---|---|---|---|
运行内存 | 1G 及以上 | 1 |
6.4 测试过程管理
6.4.1测试文档
测试文档由颜小涵主要整理汇总,汇总了在该项目开发过程中遇到的各种问题 BUG。
缺陷处理过程
定义缺陷处理过程如下:我们每次测试发现的问题会及时发布到小组沟通群里,由组长何瑾雨,后端占羽淳,前端颜小涵一同拟定解决方案来解决问题,若是可以自己调试好的小 BUG,简单调整后不会记录在主测试文档中
6.5测试结果
测试过程中,需要产生以下结果:
-
图片上传功能无法正常使用,同时部分前端功能失效,研究发现是在主页引入了无效的 js 文件,导致后续脚本全部失效,已修复。
-
后台管理同权限之间能相互修改信息,已改为只有管理权限账号可以修改信息,并且只可以修改权限低于自己的用户。
参考文献
- 基于MVC的教务管理系统的研究与实现(太原理工大学·刘飞飞)
- 四川理工学院实验室实训教学管理系统的设计与实现(电子科技大学·江宇波)
- 职业院校实验实训教学管理系统设计与实现(南京理工大学·张跃东)
- 基于J2EE的远程教学管理系统的研究(南京信息工程大学·陈康)
- 基于SSH实验室管理系统的研发(湖南师范大学·倪芳英)
- SSH框架实验教学管理研究(太原理工大学·阎治平)
- 多层架构下教务管理系统的设计与实现(华南理工大学·陈菲)
- 基于Spring Boot的教师企业实践管理系统的设计与实现(广西大学·梁莹)
- 基于SSH实验室管理系统的研发(湖南师范大学·倪芳英)
- 基于MVC的教务管理系统的研究与实现(太原理工大学·刘飞飞)
- 基于Spring与Hibernate框架实现网络教学系统(天津大学·孙烨燃)
- 海淀区职工大学教学管理系统设计与开发(中国地质大学(北京)·范金华)
- 基于J2EE技术的实验教学管理系统的设计与实现(山东大学·肖建东)
- 基于J2EE技术的实验教学管理系统的设计与实现(北京邮电大学·顾雯雯)
- 基于SSH2和JBPM的实验管理系统的设计与实现(西北师范大学·田珊珊)
本文内容包括但不限于文字、数据、图表及超链接等)均来源于该信息及资料的相关主题。发布者:代码港湾 ,原文地址:https://m.bishedaima.com/yuanma/36008.html