功能规格说明书
0. 相关概念
- Lab：《操作系统》课程实验部分的课题划分单位。每一个 Lab 对应一个课题，共有 7 个 Lab，包括 Linux 系统基础、内存管理、进程管理等。每一个 Lab 包含课下实验和课上测试。
- 评测：学生通过跳板机完成指定任务的代码编写后，将代码通过专门的接口提交至评测机。评测机根据代码运行的结果反馈一个确定的分数和相应的信息提示。
- 教程：课程实验部分的指导书。包括了实验的基本原理讲解、实验内容、题目要求等。
- 课下实验：是《操作系统》课程实验部分的一个环节。学生需要在课余时间通过跳板机完成给定任务的代码编写，可以提交评测。
- 课上测试：是《操作系统》课程实验部分的一个环节。学生在课程组统一安排下，于课内时间在机房完成的测试。测试的题目在现场给出，需要当场独立完成代码编写并通过评测。
- 讨论区：课程平台的一个模块，类似贴吧。学生可在其中发帖针对实验部分疑难问题进行提问、分享经验等，也可回帖。助教也需要浏览讨论区，解答学生提问。
- 公告：一种信息发布形式，面向的是所有的学生，内容通常涉及整个课程的安排等。
- 通知：一种信息发布形式，只针对课上测试/课下实验中的某些任务。
1. 典型用户与场景
1.1. 课程教师
课程主要由教师来讲授。目前，《操作系统》共有 5 位教师。一个课程教师可能具有如表 1 的典型特征。
| 用户 | W 老师 |
| 年龄 | ~ 40 岁 |
| 职业 | OS 课程教师 |
| 需求 | - 每一次上机考试之后查看有多少同学通过了测试 - 每年新招收助教后给助教分配权限 - 定期收取学生的实验报告 |
| 期望 | 平时科研、备课、批作业就很忙了，希望这些功能能够使用方便，信息展示明了，不需要简单但繁琐的操作 |
1.2. 课程助教
课程助教在课程中同样起到很大作用。目前课程共有助教 20 名。典型的助教画像，助教 Y、助教 P 可见表 2。
| 用户 | 助教 P | 助教 G |
| 年龄 | ~ 21 岁 | |
| 职业 | 学生、OS课程助教 | |
| 需求 | - 在每一 Lab 开始之前完成教程的编写和仓库代码的编写，并完成部署 - | - 在上机测试时随堂监考，根据需要发布通知或延长考试时间 - 时不时浏览讨论区，对学生提问进行解答 |
| 期望 | 使用方便，重复流程都能完成自动化 | |
1.3. 课程学生
课程学生是最大的用户群体，目前课程共有助教约 300 名。典型的学生画像，同学 R、同学 M 可见表 3。
| 用户 | R 同学 | M 同学 |
| 年龄 | ~ 20 岁 | |
| 职业 | 选修《操作系统》课程的学生 | |
| 需求 | - 完成课下实验和课上测试，提交实验报告 - 将实验心得发送至讨论区造福广大人民群众 | - 完成课下实验和课上测试，提交实验报告 - 代码历经曲折，想找个分最高的 commit 签出新分支开始下一个 Lab |
| 期望 | 以能通过测试为最高宗旨，讨论区查看方便，提交和评测记录一目了然，课上测试方便查看题目。上机测试时，评测能很快出结果。 | |
1.4. 典型场景
场景 1
R 同学正和其他同学一起在机房上机，他正在课程平台上阅读这次上机的题目。读完题，他却陷入了困惑：这题目到底想让我做什么呀？
与此同时，隔壁机房的助教 G 也发现题目表述不清，于是在助教前端网页上编辑了一段通知，在通知中插入几条公式并进行详细说明。为了防止疏漏，他特地切换到预览模式，仔细审阅了自己的通知，确认无误后进行发布。
通知发布后，R 同学的浏览器页面右上角立即弹出气泡，气泡中是助教 G 对题目的补充说明。看完这条气泡消息，R 同学很快明白了题意并想出了题解。随着一阵键盘敲击声，R 同学完成了代码的编写并在 git 上提交，他在网页上的显示的提交记录中选择了最近的一次 commit 提交评测。很快，该 commit 记录旁出现了 “100 分” 的字样。R 同学开心地离开了考场。
上机结束后，W 老师想看看同学们的上机成绩。他打开教师前端，点进本次上机的成绩统计。成绩统计栏目中，几个图表清晰地展示了这次上机中同学们的成绩分布。W 老师很快就掌握了同学们这次上机的情况，顺便在教师前端把所有的实验报告下载下来发给助教批改。
场景 2
课下实验的教程刚刚发布，R 同学立刻开工了。他和往常一样在跳板机上完成了代码的编写，commit 并提交评测，顺利地通过了。但是他在实验中注意到有几个细节问题很容易忽略，于是在 Markdown 中写下了实验中的一些坑点，还配图加以说明，将这些内容发送到讨论区中。
M 同学也发现这次实验中有一些细节问题，但是她提交了好几次，都没能拿到 100 分。于是她到讨论区查找相应的问题，很快找到了 R 同学的发帖。她按照 R 帖子中的内容，对自己的代码稍加修改再次提交，拿到了 100 分。AC 后，她又修改了部分代码内容进行更加深入的探索，不过这些提交没能拿到满分。她将这些探索中的学到的新知写入实验报告中，并把报告交到实验平台。
在下一次实验中，她打开本次 Lab 的 commit 记录，找到 100 分的那一次提交签出新的代码。
2. 界面原型设计
2.1. 学生端界面
R 同学和 M 同学可从图 1 所示的界面输入用户名和密码登陆学生端前端。
登陆后，将显示课程公告（图 2）。
如图 3 所示，R 同学在“进度”一栏可以看到当前的学习进度，不同的方块代表了每个任务不同的状态。点击方块，将会显示教程（图 4）和评测信息（图 5）。
M 同学将网络安全牢记于心，决定换一个更强的密码，于是他打开了图 6 所示的个人信息修改个人密码。
R 同学喜欢在讨论区（见图 7）分享自己的心得体会，他发布了一篇帖子，看起来是图 8 的样子。
2.2. 教师端界面
W 老师和助教 G、助教 P 共用教师端，他们有不同的账号。
W 老师通过如图 9 的页面登陆。登陆后即可选择当前的课程（如图 10）。
W 老师在图 11 的用户管理中添加了助教 G 和助教 P 的用户并授权，两位助教也可以登录了。W 老师还通过图 12 的界面导入了所有的课程学生。
W 老师可通过图 13 界面查看每个教学班信息。
助教 P 通过界面图 14 发布了上机考试的公告，并通过界面图 15 安排了上机测试。
考试过程中，助教 G 用图 16 界面发布了一则通知对题目进行补充说明。
考试完成后，W 老师想查看学生的成绩，于是他打开了界面图 17 的任务统计信息。他还可以查看每个同学的历次提交情况（图 18、图 19 ）。
负责评测机维护的助教，时刻盯着评测机的“心跳”。
3. 系统功能描述
3.1. Alpha 版功能
Alpha 阶段系统将具有的功能见表 4。
| 用户端 | 功能 | 验收标准 |
| 学生端 | 首页通知 |
- 支持 Markdown 格式的通知发布 - 纯文本形式通知 |
| 评测 |
- 在界面中显示所有的 Lab 分支，可以选择其中一个分支 - 选择分之后，按照时间顺序显示 commit 记录，最新的提交在最上面 - 显示的 commit 记录必须包含的信息包括 hash、commit message - 对于未提交评测的 commit，提供“提交评测”选项，用户点击后，可提交至该次试验对应的评测 - 对于已经评测的 commit，在 commit 信息旁边显示得分 - 不可重复评测同一个 commit - 在所有该分支所有评测信息的最上方显示当前课下实验（或课上测试）的最高得分 |
|
| 进度查看 |
- 用方块显示所有的任务，同一个 Lab 下所有的任务占一行 - 每一个方块中显示任务名称、开始时间、截止时间、座位、任务最终得分 - 任务的最终得分取该任务下所有提交的最高分 - 学生点击方块时，将显示该任务对应的题目 |
|
| 用户登录 |
- 用户在首页可点击“登陆” - 输入用户名和密码后尝试登陆 - 登陆成功，则进入首页通知界面 - 登录失败则返回错误提示 |
|
| 个人信息 |
- 显示用户的个人信息，包括姓名、学号、教师等 - 提供注销功能，用户点击即可退出登录 |
|
| 建议与反馈 |
- 学生可在文本框中输入对课程平台的使用反馈 - 可通过附件上传图片辅助说明 |
|
| 教师端 | 用户管理 |
- 可以添加用户、如助教、学生等，可通过文件批量导入 - 可通过权限组为助教用户批量授权 |
| 教学信息 |
- 对课程信息进行编辑、修改 - 可查看所有的选课学生信息 |
|
| 公告管理 |
- 可发布、编辑公告，支持纯文本的 Markdown - 可查看所有助教发送的公告，并进行编辑、删除等操作 |
|
| 用户登录 |
- 用户在首页可点击“登陆” - 输入用户名和密码后尝试登陆 - 登陆成功，则进入首页通知界面 - 登录失败则返回错误提示 |
|
| 评测记录 |
- 可查看每一名学生每一次提交评测的记录、包括 commit 信息、得分、评测机详细日志等 - 支持助教手动进行重测 |
|
| 评测端 | 代码评测 |
- 节点可扩充，用 U 盘启动装机后可快速扩充评测机集群 - 每一个题目用一个仓库存储，需要在课上评测/课下实验信息中填写对应的仓库信息 - 若干个评测节点轮训数据库，抓取评测请求 - 对于抓取的评测请求，分析请求内容，从 gitlab 中获取题目与评测数据进行评测，评测完成后写入数据库 |
3.2. Beta 版功能
Beta 阶段系统将具有的功能见表 5。
| 用户端 | 功能 | 验收标准 |
| 学生端 | 教程 |
- 学生可在前端网页查看对应 Lab 的教程 - 教程的形式包括文本、图片 - 教程在上机测试过程中可关闭 |
| 考试 |
- 支持 Alpha 阶段学生端所有的评测功能 - 考试之前，可登陆学生端查看考试座位 - 完成答题后，可在考试界面中签退 |
|
| 讨论区 |
- 每个学生都可发帖，支持 Markdown 和图片插入 - 每个主题帖都可添加标签 - 学生可对主题帖进行回复，也可对他人回帖进行回复 - 学生可对优秀的主题帖和回帖进行点赞 - 自己的帖子收到点赞和回复时，会有消息通知 |
|
| 教师端 | 教学信息 |
- 可以查看每个教学班的学习情况，包括班级平均分、学习困难学生 - 可查看具体每个同学的课下实验通过情况 |
| 考试信息 |
- 配置考试相关信息，如题目仓库、分支地址等 - 在考试现场对每位到场学生签到 - 以图表形式查看每次上机测试后学生成绩分布等统计信息 |
|
| 通知管理 |
- 可针对任务发布 Markdown 格式的消息提醒 - 可让学生前端直接弹窗提醒 | |
| 评测结点管理 |
- 申请评测机令牌 - 查看评测机心跳 |
4. 用户数量估计与信息采集
《操作系统》是计算机学院开设的核心专业课程，但随着计算机普及推广以及学校对计算机基础的重视，目前 6 系、21 系、23 系、42 系均开设了《操作系统》课程，学生人数在不到两年的时间内从原来仅 6 系的 200 余人迅速增加至 600 余人（包括高等理工学院、北京学院相关专业学生以及重修、补修学生）。
对于新建设的一个较为完善的系统，平台将会采集所有用户的 API 调用日志，保存在服务器的文件系统中，用以分析用户使用习惯并进行优化。同时，若服务器出现问题，也可根据日志文件尝试查找与复现问题。
5. 问题、副作用及可能的解决方案
当前系统中对性能要求最高的的模块是评测系统，尤其是在课上测试时，同学们都在较为集中的时间内提交代码进行评测，都期望尽快看到评测结果。这对评测系统的吞吐量和并发能力提出了很高的要求。
评测过程主要包含如下子过程：
- 多个评测节点轮训数据库以拉取评测请求
- 分析评测请求，并拉取对应的题目与评测样例
- 对学生提交的整个 OS 源代码进行重新编译
- 在 GXemul 中运行编译的 OS
- 用脚本检查运行结果，给与评分，并将结果写入数据库
而随着课程人数的增加，当前评测系统已经无法满足性能要求，常会出现评测慢（很久都没有信息反馈）、评测节点宕机等问题。
当前的解决方案是增强评测系统的可扩展性，在预测到需求将会骤增时，提前装机增加评测节点，由此满足性能需求。
