一、选课系统概述
由于我的工程实践项目是NLP，对算法无法进行需求分析。所以我借用比较常见的学生选课系统进行需求分析，作为本次作业。选课系统中的最主要的使用者是学生与管理员，后面将围绕一个简单的选课系统进行需求分析，不考虑抢课等复杂的功能。
二、用例图
用例图如下所示，选课系统中两个主要的角色：管理员、学生。管理员负责课程信息、学生信息与选课规则的增删改查；而学生可以选课、退课、查看课程信息、查看自己的课表，同时学生可以修改自己的个人信息，但是修改的权限低于管理员，像学号等信息学生不能修改。
三、业务类图
选课系统的业务类图如下所示。学生与管理员都有登录登出的方法，而课程、选课规则与学生都有增删改查。学生信息包括学号(id)、姓名(name)、性别(sex)、邮箱(email)、班级(class)、年级(grade)；课程包括课程编号(id)、课程名字(name)、教室(classroom)、老师(teacher)、上课周(weeks)、上课时间(times)、课程介绍(comment)、学分(score)、选课人数上限(capacity)；管理员只包括编号(id)、姓名(name)与权限(authority)。
四、数据模型
Student表
| 列名 | 数据类型 | 数据长度 | 是否可为NULL | 是否唯一 | 是否为主键 | 注释 |
| UUID | string | 256 | N | Y | Y | 通用唯一识别码 |
| sId | string | 10 | N | Y | N | 学号 |
| class | string | 256 | N | N | N | 班级 |
| grade | string | 256 | N | N | N | 年级 |
| passwd | string | 256 | N | N | N | 密码 |
| name | string | 20 | N | N | N | 姓名 |
| sex | string | 4 | N | N | N | 性别 |
| authority | int | 1 | N | N | N | 权限 |
| string | 256 | Y | N | N | 邮箱 |
Administrator表
| 列名 | 数据类型 | 数据长度 | 是否可为NULL | 是否唯一 | 是否为主键 | 注释 |
| UUID | string | 256 | N | Y | Y | 通用唯一识别码 |
| aId | string | 10 | N | Y | N | 管理员统一编号 |
| passwd | string | 256 | N | N | N | 密码 |
| name | string | 20 | N | N | N | 姓名 |
| sex | string | 4 | N | N | N | 性别 |
| authority | int | 1 | N | N | N | 权限 |
| string | 256 | Y | N | N | 邮箱 |
Course表
| 列名 | 数据类型 | 数据长度 | 是否可为NULL | 是否唯一 | 是否为主键 | 注释 |
| UUID | string | 256 | N | Y | Y | 通用唯一识别码 |
| cId | string | 10 | N | Y | N | 课程统一编号 |
| teacher | string | 256 | N | N | N | 授课老师姓名 |
| name | string | 20 | N | N | N | 课程名称 |
| weeks | string | 256 | N | N | N | 开课周 |
| times | string | 256 | N | N | N | 上课时间 |
| score | float | 10 | N | N | N | 学分 |
| classroom | string | 256 | N | N | N | 上课地点 |
| comment | string | 256 | N | N | N | 课程描述 |
| capacity | int | 3 | N | N | N | 选课人数上限 |
Rule表
| 列名 | 数据类型 | 数据长度 | 是否可为NULL | 是否唯一 | 是否为主键 | 注释 |
| UUID | string | 256 | N | Y | Y | 通用唯一识别码 |
| rId | string | 256 | N | Y | N | 规则统一编号 |
| cId | string | 256 | N | Y | N | 课程统一编号 |
| grade | string | 256 | N | N | N | 限选年级 |
| name | string | 20 | N | N | N | 课程名称 |
| class | string | 256 | N | N | N | 限选班级 |
| startTime | string | 256 | N | N | N | 生效开始时间 |
| endTime | string | 256 | N | N | N | 生效结束时间 |
CourseSelection表
| 列名 | 数据类型 | 数据长度 | 是否可为NULL | 是否唯一 | 是否为主键 | 注释 |
| UUID | string | 256 | N | Y | Y | 通用唯一识别码 |
| sId | string | 10 | N | Y | N | 学号 |
| cId | string | 256 | N | Y | N | 课程统一编号 |
五、概念原型及工作流程
学生、课程、与选课规则信息全部由管理员统一导入、修改、删除。学生可以修改自己部分个人信息，但是不能修改学号、姓名、性别等关键信息。在选课时，按照提前导入的选课规则规定什么时间段内哪个年级哪些班的学生可以选什么样的课。其中涉及可能存在的列表类型的数据统一使用json格式的字符串存储。在后台，按照微服务的思想，不同的功能分开实现，服务与服务之间通过kafka通信，避免服务之间重复调用造成逻辑混乱与流程延迟。在数据库方面，对了应对选课时间段内的集中操作，可以先使用redis，待选课完成再同步到数据库中。
在查找方面，可以使用Elasticsearch完善查找功能，方便同学根据关键词准确有效地查找课程信息，完善自己的课表。