北京理工大学大学疫苗接种系统

一.UML图

1.用例图

包含 ：登录界面 ，预约界面 ， 两个预约模块。

2.类图

区分了应用对象 ，细化了结构功能 ，同时保留了未开发的数据库相关。

3.活动图

4.顺序图

二.需求规格说明文档

1.需求和功能说明

1.1.获取的功能需求

能够进行新建、更改、取消/提醒接种/注意事项查询/接种信息进行查询

.2.功能划分

1.2.1.登录界面

区分为两种模式：管理员模式，接种者模式。
管理员账号：0，密码：0。管理员可以对接种者信息进行查询，或者补录接种者信息。
接种者模式登陆成功后返回首页面，原登陆按钮处显示姓名，点击原登录按钮可进入个人信息界面和进行退出登陆操作

1.2.2.预约服务

分为两个模块：可预约时间和，当前预约时间。
可预约时间：陈列了所有可预约场地、时间、疫苗种类；
当前预约时间：显示了当前预约的疫苗接种的场地、时间、疫苗类型和接种前注意事项。

1.2.3.接种查询

陈列了所有已经完成的接种和接种后的常见反应

附：考虑到后续可能有添加内容，所以第二、三板块都采用了上下滑动的模式进行

2.工作量展示

2.1.需求获取

2.1.1.项目前景和范围

旨在使校园新冠疫苗接种更加方便有序迅捷
该系统可以让接种者反馈不良反应，记录并提出相对的建议
对疫苗接种进行查询、预约、取消等功能
获得疫苗接种过程相应的说明和指导
汇报疫苗接种后的副作用
预约时间前获得提醒
下载新冠疫苗电子回执单

2.1.2.涉众分析

可能存在的涉众：疫苗接种者（包括教师和学生），医务工作者，后台管理员，志愿者等
####2.1.3应数据采样
（1）通过何种方式填写新冠疫苗预约信息
（2）如何评鉴当前新冠疫苗预约方式
（3）除了疫苗预约以外的期望功能
（4）是否期待更加简单便利的预约平台
（5）对新预约平台有哪些方面的需求
（6）对平台提供的功能有何建议

结果汇总：
1.大部分用户通过线上预约
2.大部分用户对当前使用的新冠疫苗预约方式较为满意
3.副作用询问与解答功能最为biyao
4.有必要推广新的线上预约平台
5.使用更便捷、共能梗完善

2.1.4.面谈

（1）用户需要进行认证：利用校园SSO等手段确保用户身份
（2）疫苗预约相关操作：包括新建、更改、取消操作
（3）细节讨论：疫苗接种管理系统的其他功能
（4）集中时间和地点分配要如何进行
（5）节后综合不良反应要如何进行
（6）接种证明材料回执单内容涵盖
（7）接种时间提醒的相关实现

2.2需求细化与建模

2.2.1.功能分解图

2.2.2.DFD

2.2.3.维规格说明

2.2.4.数据字典

2.2.5.ERD

2.3.面向对象建模

2.3.1.用例图
2.3.2UML图
ps：见第一大类
####2.3.3.需求规格说明文档
a. 引言
本文档是第7小组所开发的北京理工大学疫苗接种系统的规格需求文档。
a. 1 目的
本文档所针对的产品是北京理工大学疫苗接种系统，该产品旨在为北理工师生、疫苗接种负责人以及医护人员提供一个综合性的疫苗接种处理系统。
a. 2 预期的读者和阅读建议

1. 开发人员：正文全文和附录A。
2. 用户（接种人员）：用户界面、激励/响应序列。
3. 用户（管理人员）：用户界面、激励/响应序列。
   a. 3 产品的范围
4. 为北京理工大学师生提供一个便捷、功能全面的疫苗预约系统；
5. 为学校疫苗接种负责人提供一个能对学校疫苗接种情况进行实时掌控的系统。
6. 为疫苗接种医护人员提供一个自动登记接种记录的系统；

b. 综合描述
b.1 产品的前景
目前，新冠疫苗的接种工作在全国大范围地进行，作为一项耗时长、牵涉广的工作，只有规范化地管理才能使其正常运作、有效完成。而在开展集体接种前所使用的预约方式仍然存在着操作繁琐、功能单一、不便于接种工作的安排等情况。基于该现状，本小组决定开发一款疫苗接种系统，以帮助学校的疫苗接种工作更有序地展开。
b.2产品功能

b.3 用户类和特征
北理工师生 包括适应接种群体和不适应接种群体，希望能够借助系统判断自己属于哪一类群体，并且能够更加便捷地进行疫苗预约、接种前后相关事宜的查询。
北理工疫苗接种负责人 是该系统的后台管理人员，主要进行疫苗预约信息的审核以及接种所需座位数的查询以及安排。
疫苗接种医护人员 在进行疫苗接种后没有太多的时间进行接种信息登记。
b.4 运行环境

1. 操作系统：安卓系统
   b.5 设计和实现上的限制
2. 限制：要求接种者（用户）局限于北京理工大学的师生。

c. 外部接口需求
c.1 用户界面

1. 界面风格：简洁风格，预约服务和接种查询采用可上下滑动的浏览模式。
2. 界面操作：通过点击按钮进入各子界面、通过手机对应的返回键返回上一级界面。
3. 错误信息提示：当用户输入的信息不符合要求的格式的时候，会进行提示。
   4）各界面按钮

主界面 登录认证/用户姓名、疫苗接种服务、接种查询、电子回执。
登录界面 学号输入框、密码输入框。
注册界面 姓名、电话、身份证、学号、密码输入框。
用户信息界面 姓名、学号、身份证、退出登录。
疫苗接种服务界面 待选：（接种场地、时间、疫苗类型）预约。
已选：（接种场地、时间、疫苗类型）取消预约。
疫苗接种注意事项。
接种查询界面 第一针：是否接种、地点、时间、疫苗类型。
第二针：是否接种、地点、时间、疫苗类型。
接种后常见反应。
电子回执界面 姓名、身份证、疫苗接种信息。
c.2 软件接口

1. 接口1：接种者信息数据库

2. 接口2：接种场次数据库

3. 具体数据交换如0层图：
   

d. 系统特性
d.1 功能需求细化
需求编号 2.1
需求描述 用户在预约时能够进行新建、更改、取消的操作
源头 针对用户对于修改疫苗预约信息的需求
理由 便于用户根据实际情况对预约作出调整
优先级 1
重要性 重要
风险 中等
可变性 低

需求编号 2.2
需求描述 在接种前半小时通过短信和应用通知两种方式提醒用户进行接种
源头 针对甲方的用户能被提醒接种的需求
理由 确保用户按时接种
优先级 8
重要性 一般
风险 低
可变性 中等

需求编号 3.1
需求描述 用户能够自主进行注意事项查询以及与专家系统进行副作用问答
源头 针对用户对于接种禁忌、不良反应等信息的了解需求
理由 为用户提供细致的、可交互的相关信息查询
优先级 5
重要性 重要
风险 高
可变性 高

需求编号 3.2
需求描述 用户在接种完成后能对接种日期、地点、疫苗信息进行查询
源头 针对用户对接种信息的查询需求
理由 为用户的疫苗接种提供反馈
优先级 3
重要性 重要
风险 中等
可变性 低

需求编号 4.1
需求描述 医务工作者能够登记自己经手的接种者的接种记录
源头 针对甲方的由医务工作者登记接种信息的需求
理由 为用户的疫苗接种提供反馈
优先级 2
重要性 重要
风险 中等
可变性 高

需求编号 4.2.1
需求描述 管理员能对每条预约信息进行审核
源头 针对甲方对于预约信息的审核需求
理由 确保预约信息的正确性和完整性
优先级 6
重要性 一般
风险 中等
可变性 中等

需求编号 4.2.2
需求描述 后台要向管理员提供需要安排的座位数
源头 针对管理员对于场地管理的需求
理由 确保接种活动正常进行
优先级 4
重要性 一般
风险 中等
可变性 高

d.2 非功能需求细化

1. 安全需求
   需求编号 1
   需求描述 利用校园SSO或其他手段对用户进行有效的认证
   源头 针对甲方对于用户范围限于北理师生的要求
   理由 确保用户为北理在校师生，限定用户范围
   优先级 7
   重要性 重要
   风险 高
   可变性 高

d.3 优先级划分
相对权值 2 1 　 　 1 　 0.5 　 　 　
需求 相对收益 相对损失 总价值 价值（%） 相对成本 成本（%） 相对风险 风险（%） 优先级 顺序
1 3 3 9 13.64 5 21.74 4 20.00 0.43 7
2.1 4 5 13 19.70 3 13.04 2 10.00 1.09 1
2.2 1 1 3 4.55 2 8.70 1 5.00 0.41 8
3.1 4 3 11 16.67 4 17.39 4 20.00 0.61 5
3.2 3 4 10 15.15 3 13.04 2 10.00 0.84 3
4.1 2 4 8 12.12 2 8.70 2 10.00 0.89 2
4.2.1 2 1 5 7.58 2 8.70 2 10.00 0.55 6
4.2.2 3 1 7 10.61 2 8.70 3 15.00 0.65 4

d.4 激励/响应序列
界面 输入信号（按钮） 响应
主界面 登录认证 进入对应界面并展示相应信息
疫苗接种服务
接种查询
电子回执
用户姓名
登录界面 登录 与接种者信息库进行匹配登陆或提示失败
注册界面 注册 将相关数据录入接种者信息库或提示失败
用户信息界面 退出登录 退出当前账户
疫苗接种服务界面 待选 切换到对应界面
已选
预约 录入当前预约信息
取消预约 更改对应预约信息
d.5 业务规则
只有通过管理员账号可以对接种者的信息进行查询。普通的接种者账号只能看到自己的信息。

代码量展示：共24.6MB

2.4.系统开发
一共3个主界面
登录界面
预约界面
接种查询
ps：详见第三类前后端演示视频
最终扩展：考虑到系统即时性要求较高，所以我们将用户信息全部放在本地，减少了上传服务器等待的时间，只有将用户点击预约和取消预约这一更新操作放在了服务器上进行，这一方法可以增强软件的稳定性，防止由于同时使用用户量过多而导致超载问题。
同时，在服务器端，我们将用户分为三类：已接种完成用户、未接种完全用户和活跃用户。根据最近一段时间内请求服务器响应的次数是否大于某个阈值我们可以挑选出活跃用户，并将他们单独存储，因为很显然他们发出请求的概率可能更大；而对于一般用户我们将他们分为两类，是由于已经完成接种的用户显而易见地拥有更低的可能性进行请求响应操作，所以他们的优先级被设置为是低于未接种完全用户的。而对这两个类别内部，我们可以同样的可以采用活跃程度来排序。
在用户端，由于每部手机登陆的账号往往是固定的、少数的几个，所以可以进行简单将登陆过的账号与数据库前几位的几个账号交换位置，就能获得很高的查询效率。
由于这个软件生命周期较短、且面对学生，所以加入更为高级的算法如DNN等不仅计算资源上可能无法满足，同时计算出的结果也没有长时间使用的价值，所以最终我们考虑采用相对简单的算法来提高系统的稳定性和响应速度。

三.系统演示

apk展示：链接：https://pan.baidu.com/s/15mDpecX_y4w3772FaDgPpQ
提取码：4rrx

如下为当前版本软件3个已完成部分的视频演示

四.人员分工

总结：项目中组长劳苦功高，组员们也基本按时完成各项任务，前期偶有技术难题或需求模糊也能很快通过学习和甲方沟通来解决，感谢小组全员的通力合作。