标签：助教 功能 评测 课程 学生 规格 说明书 提交 commit

0. 相关概念

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

1. 典型用户与场景

1.1. 课程教师

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

表 1 - 课程教师画像

用户	W 老师
年龄	~ 40 岁
职业	OS 课程教师
需求	- 每一次上机考试之后查看有多少同学通过了测试 - 每年新招收助教后给助教分配权限 - 定期收取学生的实验报告
期望	平时科研、备课、批作业就很忙了，希望这些功能能够使用方便，信息展示明了，不需要简单但繁琐的操作

1.2. 课程助教

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

表 2 - 助教画像

用户	助教 P	助教 G
年龄	~ 21 岁
职业	学生、OS课程助教
需求	- 在每一 Lab 开始之前完成教程的编写和仓库代码的编写，并完成部署 - 重构上一届助教开发的 OS 课程平台	- 在上机测试时随堂监考，根据需要发布通知或延长考试时间 - 时不时浏览讨论区，对学生提问进行解答
期望	使用方便，重复流程都能完成自动化

1.3. 课程学生

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

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

3. 系统功能描述

3.1. Alpha 版功能

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

表 4 - Alpha 阶段功能

用户端	功能	验收标准
学生端	首页通知	- 支持 Markdown 格式的通知发布 - 纯文本形式通知
	评测	- 在界面中显示所有的 Lab 分支，可以选择其中一个分支 - 选择分之后，按照时间顺序显示 commit 记录，最新的提交在最上面 - 显示的 commit 记录必须包含的信息包括 hash、commit message - 对于未提交评测的 commit，提供“提交评测”选项，用户点击后，可提交至该次试验对应的评测 - 对于已经评测的 commit，在 commit 信息旁边显示得分 - 不可重复评测同一个 commit - 在所有该分支所有评测信息的最上方显示当前课下实验（或课上测试）的最高得分
	进度查看	- 用方块显示所有的任务，同一个 Lab 下所有的任务占一行 - 每一个方块中显示任务名称、开始时间、截止时间、座位、任务最终得分 - 任务的最终得分取该任务下所有提交的最高分 - 学生点击方块时，将显示该任务对应的题目
	用户登录	- 用户在首页可点击“登陆” - 输入用户名和密码后尝试登陆 - 登陆成功，则进入首页通知界面 - 登录失败则返回错误提示
	个人信息	- 显示用户的个人信息，包括姓名、学号、教师等 - 提供注销功能，用户点击即可退出登录
	建议与反馈	- 学生可在文本框中输入对课程平台的使用反馈 - 可通过附件上传图片辅助说明
教师端	用户管理	- 可以添加用户、如助教、学生等，可通过文件批量导入 - 可通过权限组为助教用户批量授权
	教学信息	- 对课程信息进行编辑、修改 - 可查看所有的选课学生信息
	公告管理	- 可发布、编辑公告，支持纯文本的 Markdown - 可查看所有助教发送的公告，并进行编辑、删除等操作
	用户登录	- 用户在首页可点击“登陆” - 输入用户名和密码后尝试登陆 - 登陆成功，则进入首页通知界面 - 登录失败则返回错误提示
	评测记录	- 可查看每一名学生每一次提交评测的记录、包括 commit 信息、得分、评测机详细日志等 - 支持助教手动进行重测
评测端	代码评测	- 节点可扩充，用 U 盘启动装机后可快速扩充评测机集群 - 每一个题目用一个仓库存储，需要在课上评测/课下实验信息中填写对应的仓库信息 - 若干个评测节点轮训数据库，抓取评测请求 - 对于抓取的评测请求，分析请求内容，从 gitlab 中获取题目与评测数据进行评测，评测完成后写入数据库

3.2. Beta 版功能

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

表 5 - Beta 阶段功能

用户端	功能	验收标准
学生端	教程	- 学生可在前端网页查看对应 Lab 的教程 - 教程的形式包括文本、图片 - 教程在上机测试过程中可关闭
	考试	- 支持 Alpha 阶段学生端所有的评测功能 - 考试之前，可登陆学生端查看考试座位 - 完成答题后，可在考试界面中签退
	讨论区	- 每个学生都可发帖，支持 Markdown 和图片插入 - 每个主题帖都可添加标签 - 学生可对主题帖进行回复，也可对他人回帖进行回复 - 学生可对优秀的主题帖和回帖进行点赞 - 自己的帖子收到点赞和回复时，会有消息通知
	实验报告提交	- 完成实验报告后，学生可在对应 Lab 下提交实验报告 - 支持 Markdown 格式的输入或直接上传文件
教师端	教学信息	- 可以查看每个教学班的学习情况，包括班级平均分、学习困难学生 - 可查看具体每个同学的课下实验通过情况
	考试信息	- 配置考试相关信息，如题目仓库、分支地址等 - 在考试现场对每位到场学生签到 - 以图表形式查看每次上机测试后学生成绩分布等统计信息
	通知管理	- 可针对任务发布 Markdown 格式的消息提醒 - 可让学生前端直接弹窗提醒

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

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

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

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

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

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

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

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

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

标签：助教,功能,评测,课程,学生,规格,说明书,提交,commit
来源： https://www.cnblogs.com/it-was-you-and-me/p/16163388.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。