第一章 概要设计
1.1 系统目标
自新冠肺炎疫情爆发,全世界进入了混乱无序的状态,直到今天已经有超过五百万的民众失去了生命,这两年以来新冠肺炎也变成了世界级的重大难题,社会各界都面临着新冠疫情所带来的挑战。由于新冠肺炎疫情全球各国各行各业都经历了一段时间的关闭,直接影响了教育,工农业,商业活动的进程。时至今日即使大部分国家的人民已经接种了新冠肺炎的加强针疫苗,但是新冠病毒的突变毒株尚未彻底消灭,依旧对人类社会造成着严重的威胁和伤害。在国内虽然基本控制了疫情的蔓延,但是病例数目却从未降到零,因此我们更需要注重防范,社会各阶层,各领域的机构和组织都需要制定符合自身的防疫政策。由于大学校园是科技教育文化的重要领地,拥有来自全国乃至全世界的学者和人才,每次假期期间的出校和返校,势必带来了安全隐患,因此决定开发一个平台来统一管理疫情相关的事务。
本系统的开发在很大程度上集中了事务的处理,包括填报体温,提交当前地址,提交外出目的地等零碎任务,也让全校师生的数据有了保存和分析的基础条件。校内防疫政策的发布和调整保持一致,可避免不同学院之间的信息不同步和信息不对称,减少了辅导员老师和各个班委的工作量。从而降低了疫情带来的风险,也让管理制度变得更加灵活,人性化。
1.2 系统主要功能
本系统的用户分为管理员和一般用户,一般用户又分为学生和辅导员。
管理员权限最高,能够删除和添加任何一个用户,可以发布通知信息,可以修改用户的个别个人信息,可以看到全部用户的提交信息。可以给辅导员发送信息,可以收到辅导员发送的信息。
学生用户的功能为填写返校前健康日报,填写返校后健康日报,位置报送,填写外出申请,查看疫情消息,查看进出二维码,查看返校二维码,核算检测签到等。
辅导员用户的功能为审批返校前健康日报,查看内容是否有异常,学生在返校前14天内,如健康日报内容无异常情况,则辅导员给予返校二维码。审批返校后健康日报,如内容有异常问题,则迅速按照疫情防控办法来处理。审批外出申请表,给予申请人进出二维码。
1.3 设计约束和限制
1.3.1 编程语言限制
本系统的后端的使用Java程序设计语言,开发框架使用springboot开源框架,前端界面采用HTML + CSS + JavaScript语言,框架采用Vue,数据库使用MySQL,持久层框架采用MyBatis。
1.3.2 工具约束
系统的开发过程使用多种开发工具,后端选择Eclipse,因为企业版Eclipse拥有比VScode更强的项目部署能力,对项目的管理和代码的管理,规范等问题上Eclipse略胜一筹。
在前端开发上选择使用VScode,是基于前端代码中使用多种标签和符号的配对,更适合格式化文本标记语言,且界面更开阔。
1.3.3 性能约束
保证网络连接的稳定性,降低断网情况发生的概率。能在用户提出登陆/退出请求后快速响应,保证 3s 内实现网络连接和断开。对用户使用的平台其他功能完整记录不缺失,查询保证在 3s 内完成响应。保证用户隐私信息的安全。
1.3.4 使用场景
本系统一般用于学校要求学生填报各种类型的信息时和学生需要进出学校时,本系统的使用更多是为了统一化工作平台,学校方面方便管理和统计数据。
1.3.5 功能设计具体要求
对于同一账户,同一时间只允许一个客户端进行登录;提交健康日报每日只能一次;进出二维码在达到时间限制时会变色,说明已过期。学生提交的每一个健康日报都会被存储在系统内存中。
第二章 详细设计
本文将采用RUP“4+1”视图模型来描述本软件系统的体系结构。"4+1"模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。每一个视角只关心系统的一个侧面,5个视角结合在一起才能够反映系统的软件体系结构的全部内容。
2.1 数据流描述
数据流名称
|
简述
|
定义
|
来源
|
去向
|
登录系统请求
|
用户使用账号和密码进行系统登录
|
登录请求=登录用户名+密码
|
用户
|
用户,服务器
|
个人信息
|
用户登陆自己账号后,查看自己信息
|
用户信息=用户名+其他个人信息
|
用户
|
用户,服务器
|
填报返校前日报
|
学生用户登录系统后填写返校前健康日报
|
日报信息=体温+出行轨迹+身体状况
|
用户(学生)
|
用户(辅导员),服务器
|
填报到校后日报
|
学生用户登录系统后填写到校后健康日报
|
日报信息=体温+身体状况+健康码截图
|
用户(学生)
|
用户(辅导员),服务器
|
填报在校日报
|
学生用户登录系统后填写在校健康日报
|
日报信息=体温+身体状况+健康码截图
|
用户(学生)
|
用户(辅导员),服务器
|
位置报送
|
学生用户登录系统后,把当下位置发送给辅导员
|
位置报送=定位位置+详细位置
|
用户(学生)
|
用户(辅导员),服务器
|
查看进出二维码
|
学生用户登录系统后,查看自己的进出码
|
进出二维码=二维码
|
服务器,用户(辅导员)
|
用户(学生)
|
查看返校二维码
|
学生用户登录系统后,查看自己的返校码
|
返校二维码=二维码
|
服务器,用户(辅导员)
|
用户(学生)
|
填写外出申请
|
学生登录系统后,可填写申请表外出
|
申请表=目的地+外出目的+往返时间
|
用户(学生)
|
用户(辅导员),服务器
|
核算检测签到
|
用户可以通过扫码或填表来签到
|
签到信息=姓名+学院+年级+时间
|
用户(学生,辅导员)
|
服务器
|
填写返乡统计表
|
学生用户登录系统后,填写返乡统计表
|
返乡信息=姓名+学号+年级+学院+返乡日期+是否留校情况
|
用户(学生)
|
用户(辅导员),服务器
|
审批返校前日报
|
辅导员用户可以打开审批学生用户提交的健康日报
|
审批过程=打开查阅+审批通过
|
用户(辅导员)
|
用户(学生),服务器
|
审批到校后日报
|
辅导员用户可以打开审批学生用户提交的健康日报
|
审批过程=打开查阅+审批通过
|
用户(辅导员)
|
用户(学生),服务器
|
审批到校后日报
|
辅导员用户可以打开审批学生用户提交的健康日报
|
审批过程=打开查阅+审批通过
|
用户(辅导员)
|
用户(学生),服务器
|
查看位置报送
|
辅导员可以查看学生提交的位置报送
|
位置信息=定位位置+详细位置
|
用户(辅导员)
|
用户(学生),服务器
|
通过返校二维码
|
辅导员查看学生的返校前日报,学生获得返校二维码
|
返校二维码=二维码
|
用户(辅导员)
|
用户(学生),服务器
|
通过进出二维码
|
辅导员查看学生的外出申请,学生获得进出二维码
|
进出二维码=二维码
|
用户(辅导员)
|
用户(学生),服务器
|
查看核算人数
|
辅导员可查看核算检测人数
|
核算人数=姓名+学院+专业
|
用户(辅导员)
|
用户(学生),服务器
|
查看返乡统计表
|
辅导员可以查看学生填写的核算检测表
|
返乡统计表=姓名+是否返乡+返乡时间
|
用户(辅导员)
|
用户(学生),服务器
|
下发疫情相关通知
|
系统管理员下发疫情相关的通知
|
通知=事件+时间+地点+内容
|
管理员
|
用户,服务器
|
删除/添加用户(学生,辅导员)
|
管理可以添加或删除用户
|
删除/添加用户=账户+信息
|
管理员
|
服务器
|
a. 顶层数据流图
图-1 总数据流图
b. 第零层数据流图
图-2 第零层数据流图
c. 登录模块详细数据流
图-3 登录模块
d. 查看个人信息详细数据流
图-4 查看个人信息
e. 修改个人信息详细数据流
图-5 修改个人信息
f. 填报健康日报(返校前,返校后,在校期间)
图-6 填报健康日报
g. 位置报送详细数据流
图-7 位置报送
h. 查看二维码(返校码,进出码)数据流
图-8 查看二维码
i. 填写外出申请详细数据流
图-9 填写外出申请
j. 核酸签到详细数据流
图-10 核算检测签到
k. 返乡统计详细数据流
图-11 返乡信息统计
l. 审批日报详细数据流(返校前,返校后,在校期间)
图-12 审批健康日报
m. 查看位置报送详细数据流
图-13 查看位置报送
n. 批准二维码(返校码,进出码)
图-14 批准二维码
o. 查看核算统计数据流
图-15 查看核算人数统计
p. 查看返乡统计数据流
图-16 查看返乡统计
q. 下发通知详细数据流
图-17 下发通知
r. 管理用户详细数据流
图-18 管理用户模块
2.2 用例视图描述
本高校疫情管理系统有三类用户,分别为系统管理员,学生用户和辅导员用户。其中系统管理员权限最大,可管理学生和辅导员,辅导员可以管理学生用户,学生用户权限最小。如下为各个用户之间的关系和每一种用户的功能模块用例图。用例的每一个模块与子模块之间的关系。
a. 学生用户用例试图
图-20 学生用户用例试图
b. 辅导员用户用例试图
图-21 辅导员用户用例图
c. 用户之间关系图
图-19 用户间关系图
d. 系统管理员用例试图
图-22 管理员用例图
2.3 逻辑视图描述
下文中用类图和顺序图来描述系统的模型。类图中包含有各个实体类的属性,方法等信息,除此之外类与类之间的继承,实现关系。主要的实体类有:学生类,辅导员类,管理员类。由于上述三种实体均属于用户,所以还需要一个抽象类,来统一管理。除此之外,还需要一个UserInterface接口来获取每一个类的共有的属性。
返校前健康日报,返校后健康日报和在校期间健康日报这三个实体类均属于日报类(抽象类)的子类。外出表,核算签到表,返乡统计表,位置表均为实体类,且没有父类。有一个抽象类可以获取每一个实体类中共有的属性。
2.3.1 类图描述
a. 用户实体的类模型视图
图-23 用户类的继承实现关系
b. 其他实体的类模型视图
图-23 类与类之间的静态关系