0. 相关概念

• Lab：《操作系统》课程实验部分的课题划分单位。每一个 Lab 对应一个课题，共有 7 个 Lab，包括 Linux 系统基础、内存管理、进程管理等。每一个 Lab 包含课下实验和课上测试。
• 评测：学生通过跳板机完成指定任务的代码编写后，将代码通过专门的接口提交至评测机。评测机根据代码运行的结果反馈一个确定的分数和相应的信息提示。
• 教程：课程实验部分的指导书。包括了实验的基本原理讲解、实验内容、题目要求等。
• 课下实验：是《操作系统》课程实验部分的一个环节。学生需要在课余时间通过跳板机完成给定任务的代码编写，可以提交评测。
• 课上测试：是《操作系统》课程实验部分的一个环节。学生在课程组统一安排下，于课内时间在机房完成的测试。测试的题目在现场给出，需要当场独立完成代码编写并通过评测。
• 讨论区：课程平台的一个模块，类似贴吧。学生可在其中发帖针对实验部分疑难问题进行提问、分享经验等，也可回帖。助教也需要浏览讨论区，解答学生提问。

1. 典型用户与场景

1.1. 课程教师

课程主要由教师来讲授。目前，《操作系统》共有 5 位教师。一个课程教师可能具有如表 1 的典型特征。

1.2. 课程助教

课程助教在课程中同样起到很大作用。目前课程共有助教 20 名。典型的助教画像，助教 Y、助教 P 可见表 2。

1.3. 课程学生

课程学生是最大的用户群体，目前课程共有助教约 300 名。典型的学生画像，同学 R、同学 M 可见表 3。

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. 界面原型设计

3. 系统功能描述

3.1. Alpha 版功能

Alpha 阶段系统将具有的功能见表 4。

3.2. Beta 版功能

Beta 阶段系统将具有的功能见表 5。

4. 用户数量估计与信息采集

《操作系统》是计算机学院开设的核心专业课程，但随着计算机普及推广以及学校对计算机基础的重视，目前 6 系、21 系、23 系、42 系均开设了《操作系统》课程，学生人数在不到两年的时间内从原来仅 6 系的 200 余人迅速增加至 600 余人（包括高等理工学院、北京学院相关专业学生以及重修、补修学生）。

对于新建设的一个较为完善的系统，平台将会采集所有用户的 API 调用日志，保存在服务器的文件系统中，用以分析用户使用习惯并进行优化。同时，若服务器出现问题，也可根据日志文件尝试查找与复现问题。

5. 问题、副作用及可能的解决方案

当前系统中对性能要求最高的的模块是评测系统，尤其是在课上测试时，同学们都在较为集中的时间内提交代码进行评测，都期望尽快看到评测结果。这对评测系统的吞吐量和并发能力提出了很高的要求。

评测过程主要包含如下子过程：

• 多个评测节点轮训数据库以拉取评测请求
• 分析评测请求，并拉取对应的题目与评测样例
• 对学生提交的整个 OS 源代码进行重新编译
• 在 GXemul 中运行编译的 OS
• 用脚本检查运行结果，给与评分，并将结果写入数据库

而随着课程人数的增加，当前评测系统已经无法满足性能要求，常会出现评测慢（很久都没有信息反馈）、评测节点宕机等问题。

当前的解决方案是增强评测系统的可扩展性，在预测到需求将会骤增时，提前装机增加评测节点，由此满足性能需求。