尧图网页设计 
简介这份在线教育网系统需求分析说明书面向学校信息化建设者、软件工程专业学生及项目开发人员为构建B/S架构的在线教育平台提供完整的需求指导。文档围绕学员管理、网上教学管理与校园信息管理三大模块展开详细梳理了权限设置、角色管理、栏目维护、班级科目创建、教学资料上传下载、在线考试与自动改卷等业务功能并配有UML用例图与参与者描述明确管理员、教师、学员三类角色的行为边界。资源包内含1个doc文档约2.21MB内容涵盖项目背景、用户环境、功能清单与需求分析技术栈涉及.Net Framework 2.0、Oracle 9i及Rational Rose、PowerDesigner建模工具。目前已有1583人学习适合需要撰写需求规格说明书、开展课程设计或搭建在线教育平台的读者参考可帮助快速理解系统功能划分与用例建模思路。1. 在线教育网系统需求分析说明书从一份文档到一套能落地的建模范式做过在线教育平台的人都有一个共识真正拖慢进度的从来不是写代码而是需求阶段没把角色、权限、课程状态机这三件事说清楚。一份合格的在线教育网系统需求分析说明书本质上是把“谁在什么条件下能对哪门课做什么操作”翻译成 B/S 架构下可建模、可验证、可交付的技术契约。它面向的是要交付真实系统的开发团队不是交作业的学生。热搜里 uml 用例图、uml 类图、E-R 图、Oracle 这些词频繁出现恰恰说明大家卡在同一个地方知道要画图但不知道画到什么颗粒度才算够用。这篇笔记就按我实际做项目的顺序把这份说明书从结构、建模、数据设计到评审验收整条链路拆开讲让你拿到就能照着写。2. 需求分析说明书该写哪几块B/S 在线教育系统的文档骨架在线教育系统的需求文档和普通管理系统最大的区别在于它同时存在“内容生产”和“内容消费”两条主线讲师侧要管课程、章节、题库、直播排期学员侧要管选课、学习进度、订单、考试。两条线共用一套用户体系和权限模型所以文档骨架必须先把边界划清楚否则后面 UML 建模会互相打架。2.1 五段式结构从业务目标到验收标准我一般把说明书拆成五段每段都有明确的交付物不写完不进入下一段段落核心内容交付物常见返工点业务概述平台定位、目标用户、核心业务流程业务流程图 角色清单角色漏了助教/运营功能需求按模块拆解功能点用例图 用例规约用例粒度太粗数据需求实体、属性、关系E-R 图 数据字典忽略历史数据非功能需求性能、安全、并发指标表只写“高性能”验收标准每个用例的可测条件验收清单无法量化业务概述这一段很多人写得像宣传文案其实它只需要回答三个问题平台服务谁、他们来干什么、平台靠什么盈利。在线教育场景下角色至少包括学员、讲师、助教、运营、管理员五类少一个后面权限模型就要推倒重来。功能需求按模块拆我习惯分成用户中心、课程管理、学习中心、订单支付、考试测评、直播互动、后台运营七个模块每个模块再往下拆用例。非功能需求是最容易被敷衍的部分。在线教育系统有几个硬指标必须写进文档课程视频并发播放数、直播延迟上限、订单支付成功率、考试提交的幂等性要求。这些指标直接决定后面架构选型和数据库设计不写清楚开发和测试都没有依据。2.2 用例规约怎么写才不会被开发怼用例图只是索引真正让开发能动手的是用例规约。一个完整的用例规约包含用例编号、名称、参与者、前置条件、基本流程、备选流程、后置条件、业务规则。以“学员选课”为例前置条件学员已登录且账号状态正常基本流程进入课程详情 → 校验是否已选 → 校验课程容量 → 生成订单 → 跳转支付备选流程课程已满 → 提示并推荐相似课程重复选课 → 直接进入学习中心后置条件订单记录写入课程容量减一业务规则同一课程不可重复购买未支付订单 30 分钟自动关闭这里有个血泪经验备选流程一定要写全开发写代码时最怕的就是“这种情况怎么办”。你少写一条联调时就多吵一次。业务规则里的数字30 分钟、容量上限必须和运营确认不能自己拍脑袋。2.3 把热搜里的 UML 图落到文档对应位置很多人搜 uml 用例图、uml 类图、uml 中的动态结构图包括哪些其实是想知道每种图放在文档哪个位置。我的对应关系是用例图 → 功能需求章节每个模块一张类图 → 数据需求章节描述实体间静态关系时序图 / 活动图 / 状态图 → 关键流程章节描述动态行为E-R 图 → 数据需求章节和类图互补动态结构图在 UML 里指的就是时序图、协作图、活动图、状态图这四类在线教育系统里最常用的是时序图描述选课、支付、直播推流和状态图描述课程状态、订单状态。状态图尤其重要课程从“草稿→待审核→已上架→已下架”的流转订单从“待支付→已支付→已退款”的流转画清楚能省掉大量沟通成本。3. 用 UML 把在线教育核心流程建模用例图、类图、时序图的画法与参数UML 建模不是画得漂亮就行关键是颗粒度和一致性。我见过太多文档用例图和类图对不上开发照着做发现少字段。这一章按“先静态后动态”的顺序把三类核心图的画法和参数讲透。3.1 用例图角色与用例的边界怎么划在线教育系统的用例图我一般画三张学员视角、讲师视角、管理视角。不画一张大图的原因是角色太多连线会变成蜘蛛网评审时没人看得清。学员视角的核心用例浏览课程、搜索课程、选课下单、支付、观看视频、做练习、参加考试、查看成绩、评价课程、申请退款。讲师视角创建课程、编辑章节、上传视频、组卷、发布考试、查看学员数据、发起直播。管理视角审核课程、管理用户、处理退款、配置轮播、查看报表。画用例图有三个参数要定用例粒度一个用例对应一个完整的用户目标不要拆成“点击按钮”这种操作级。include 和 extend 的使用必须执行的公共步骤用 include如“支付”include“校验订单”可选扩展用 extend如“选课”extend“使用优惠券”。角色继承助教继承讲师的部分权限时用泛化箭头但不要为了省事把管理员和运营合并。注意用例图里不要出现数据库、接口、类这些技术元素它是业务视角的图混入技术元素会让业务方看不懂评审直接卡住。3.2 类图实体、属性、关系的设计参数类图是后面建表的基础属性设计错了数据库就要改。在线教育系统的核心类包括User用户、Student、Teacher、Course课程、Chapter章节、Lesson课时、Order订单、Payment支付、Exam考试、Question题目、AnswerRecord答题记录、Enrollment选课记录。每个类的关键属性// 课程类核心字段设计 public class Course { private Long courseId; // 主键雪花ID private String title; // 课程标题唯一索引 private Long teacherId; // 讲师ID外键 private Integer status; // 状态0草稿 1待审核 2已上架 3已下架 private BigDecimal price; // 价格精度两位小数 private Integer capacity; // 容量上限0表示不限 private Integer enrolledCount; // 已选人数冗余字段 private Date createTime; // 创建时间 private Date updateTime; // 更新时间 }类之间的关系要标清楚Student 和 Course 是多对多通过 Enrollment 关联Course 和 Chapter 是一对多Chapter 和 Lesson 是一对多Order 和 Course 是多对一Exam 和 Question 是多对多通过 ExamQuestion 关联。多重性标注1、0..、1..不能省它直接决定外键建在哪张表。类图里还有一个容易忽略的点抽象类。User 可以设计成抽象类Student 和 Teacher 继承它公共属性用户名、密码、手机号、状态放父类角色特有属性放子类。这样权限校验时统一操作 User 即可。3.3 时序图选课支付和直播推流两条关键链路时序图描述对象间的消息传递顺序在线教育系统里最值得画的两条链路是选课支付和直播推流。选课支付的时序学员 → 课程服务校验课程状态和容量→ 订单服务创建订单→ 支付服务调用支付网关→ 回调订单服务更新订单状态→ 课程服务增加选课记录、容量减一→ 通知学员。这条链路里有两个关键参数订单超时时间一般 30 分钟和支付回调的幂等键用订单号做唯一约束。直播推流的时序讲师端 → 推流服务鉴权、分配推流地址→ 流媒体服务器 → 学员端拉流。这里要标注清楚鉴权 token 的有效期和拉流地址的过期时间一般 token 有效期 2 小时拉流地址 4 小时。画时序图时激活条对象执行操作的时期要画准确它反映了对象的生命周期。消息编号建议加上方便评审时逐条对照。返回消息用虚线箭头异步消息用开放箭头这些细节在软考中级 UML 建模里是考点在实际项目里是沟通效率的保障。4. E-R 图到 Oracle 建表在线教育系统的数据落地UML 类图解决的是业务对象关系E-R 图解决的是数据库落地。两者视角不同类图可以有继承、多态E-R 图必须扁平化成表和字段。在线教育系统数据量增长最快的是学习记录和答题记录设计时就要考虑分区和索引。4.1 从类图到 E-R 图的转换规则转换规则我总结成四条普通类转表属性转字段主键选无业务含义的自增或雪花 ID。一对多关系外键建在多的一方。Course 和 Chapter外键 chapter.course_id。多对多关系拆中间表。Student 和 Course 拆 enrollment 表字段为 student_id、course_id、enroll_time、progress。继承关系两种策略单表继承所有角色一张 user 表加 role 字段或类表继承user 表存公共字段student、teacher 表存特有字段。在线教育系统我推荐类表继承因为讲师和学员的特有字段差异大。E-R 图里要标注清楚主键PK、外键FK、唯一约束UK和索引。课程表的 title 加唯一索引订单表的 order_no 加唯一索引学习记录表的 (student_id, lesson_id) 加联合唯一索引防止重复记录。4.2 Oracle 建表脚本与关键参数Oracle 是在线教育系统常见的选择尤其在中大型机构。建表时几个参数必须显式指定-- 课程表建表脚本 CREATE TABLE t_course ( course_id NUMBER(20) NOT NULL, title VARCHAR2(200) NOT NULL, teacher_id NUMBER(20) NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, price NUMBER(10,2) DEFAULT 0 NOT NULL, capacity NUMBER(8) DEFAULT 0 NOT NULL, enrolled_count NUMBER(8) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, update_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT pk_course PRIMARY KEY (course_id), CONSTRAINT uk_course_title UNIQUE (title) ); -- 索引按讲师和状态查询课程列表 CREATE INDEX idx_course_teacher ON t_course(teacher_id, status); -- 注释 COMMENT ON TABLE t_course IS 课程表; COMMENT ON COLUMN t_course.status IS 0草稿 1待审核 2已上架 3已下架;参数说明NUMBER(20) 用于雪花 IDNUMBER(10,2) 用于金额保证两位小数VARCHAR2 用字节长度还是字符长度取决于字符集AL32UTF8 下 VARCHAR2(200) 能存 200 个字符。DATE 类型在 Oracle 里包含时分秒不需要 TIMESTAMP 除非要毫秒精度。分页查询是在线教育系统列表页的高频操作Oracle 12c 之后可以用 OFFSET FETCH-- Oracle 12c 分页 SELECT course_id, title, price FROM t_course WHERE status 2 ORDER BY create_time DESC OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY;12c 之前用 ROWNUM 嵌套写法繁琐且容易出错。如果项目还在用 11g建议封装成存储过程或视图避免每个查询都写嵌套。4.3 学习记录表的分区与索引策略学习记录是在线教育系统增长最快的表一个学员看一节课就产生一条记录日增可能几十万。这张表必须做分区按 create_time 做范围分区每月一个分区CREATE TABLE t_learn_record ( record_id NUMBER(20) NOT NULL, student_id NUMBER(20) NOT NULL, lesson_id NUMBER(20) NOT NULL, course_id NUMBER(20) NOT NULL, progress NUMBER(5,2) DEFAULT 0, last_time DATE, create_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT pk_learn_record PRIMARY KEY (record_id, create_time) ) PARTITION BY RANGE (create_time) ( PARTITION p202401 VALUES LESS THAN (TO_DATE(2024-02-01,YYYY-MM-DD)), PARTITION p202402 VALUES LESS THAN (TO_DATE(2024-03-01,YYYY-MM-DD)) );分区键必须包含在主键里这是 Oracle 分区表的硬性要求。查询时带上 create_time 条件才能命中分区裁剪否则全分区扫描。索引建在 (student_id, lesson_id) 上用于查询某个学员某节课的记录。提示Oracle 中 TRUNC(SYSDATE) 常用于按天统计TRUNC(SYSDATE, MM) 按月统计。学习时长统计用 SUM(progress) 配合 GROUP BY 即可但要注意 progress 是百分比还是秒数设计时统一成秒数更灵活。5. 需求评审与避坑在线教育系统文档最容易翻车的五个地方需求评审是文档交付前的最后一道关也是翻车最集中的环节。下面五条是我踩过的坑每条按现象、原因、解决写。5.1 用例图和类图对不上开发照着做发现少字段现象评审时用例图里“学员评价课程”这个用例类图里找不到评价实体开发问评价数据存哪当场卡住。原因用例图和类图分开画画完没有交叉核对。用例图关注行为类图关注数据但每个用例背后都有数据支撑。解决画完类图后逐个用例检查是否有对应实体。评价用例对应 Evaluation 类字段包括 evaluation_id、student_id、course_id、score、content、create_time。建立一张“用例-实体对照表”评审时逐行过。5.2 订单状态机没画支付回调把订单改成错误状态现象支付成功后订单状态变成“已支付”但退款回调又把状态改成“已退款”而实际退款还没到账学员看到状态混乱。原因订单状态流转没有用状态图定义清楚开发各自为政回调逻辑互相覆盖。解决用状态图定义订单全生命周期待支付 → 已支付 → 已退款 / 已关闭。每个状态转换标注触发事件和守卫条件。支付回调只能把“待支付”改成“已支付”退款回调只能把“已支付”改成“已退款”其他转换一律拒绝。状态字段加版本号做乐观锁防止并发覆盖。5.3 课程容量并发扣减超卖现象课程容量 100实际卖出 105 份运营发现后紧急下架。原因需求文档只写了“校验课程容量”没写并发场景下的扣减策略。开发用“先查再改”的写法两个请求同时查到容量剩 1都判断可以选都扣减。解决文档里明确写“容量扣减必须用数据库原子操作”。实现上用UPDATE t_course SET enrolled_count enrolled_count 1 WHERE course_id ? AND enrolled_count capacity根据影响行数判断是否成功。或者用 Redis 预扣减加消息队列异步落库。这个规则必须写进非功能需求章节。5.4 Oracle 监听服务起不来开发环境集体瘫痪现象早上到公司开发环境连不上 Oracle报 ORA-12541 TNS 无监听程序。原因服务器重启后监听服务没自启或者 listener.ora 配置被改。热搜里 oracle 监听服务无法启动是高频问题。解决文档里加一节“环境部署说明”写明监听服务自启配置。Linux 下用lsnrctl start启动检查lsnrctl status。如果是端口被占用netstat -tlnp | grep 1521排查。修改默认监听端口后要同步更新 tnsnames.ora 和客户端的连接配置。这类环境问题写进文档能省掉新成员大量排查时间。5.5 需求文档没写数据权限学员能查到别人成绩现象测试时发现学员 A 通过改 URL 参数能查到学员 B 的考试成绩。原因功能需求只写了“查看成绩”没写数据权限规则。开发只做了功能鉴权是否登录没做数据鉴权只能看自己的。解决文档里每个查询类用例都要加“数据权限”一栏。查看成绩的数据权限规则是“仅本人”查看班级报表的是“仅本班讲师”查看全平台报表的是“管理员”。实现上在 SQL 里强制拼 student_id 条件或者在服务层做统一拦截。这条规则不写等保测评和渗透测试都会挂。6. 让说明书真正被用起来一个可复用的评审清单和迭代习惯文档写完不是终点能被开发、测试、运维持续引用才是。我现在的习惯是给说明书配一份评审清单每次迭代前过一遍迭代后更新一次。清单分四块业务完整性、模型一致性、数据可落地性、非功能可测性。业务完整性检查角色是否覆盖全、每个角色的核心用例是否都有规约、备选流程是否写全。模型一致性检查用例图和类图是否对得上、时序图的消息是否都有对应方法、状态图是否覆盖所有状态转换。数据可落地性检查每个实体是否有建表脚本、索引是否覆盖高频查询、分区策略是否明确。非功能可测性检查每个指标是否有具体数值、是否有对应的测试方法。这份清单我一般做成表格评审时逐项打勾有问题的当场记录负责人和截止时间。迭代结束后把本次新增的用例、实体、状态转换补进文档保持文档和代码同步。文档一旦和代码脱节下次就没人看了。还有一个具体技巧把 E-R 图和建表脚本放在同一章节图下面紧跟 DDL评审时对照着看发现字段对不上当场改。Oracle 的字段类型和 Java 类型映射也列一张表NUMBER(20) 对应 LongNUMBER(10,2) 对应 BigDecimalVARCHAR2 对应 StringDATE 对应 java.util.Date 或 LocalDateTime。这张表能避免很多类型转换的 bug。我自己的教训是早期做项目时觉得需求文档是走形式结果开发到一半发现订单状态没定义清楚返工两周。后来老老实实把状态图、时序图、E-R 图画全评审时拉着开发和测试一起过反而一次通过。文档的价值不在于写得多漂亮而在于每个看图的人都能找到自己需要的答案。希望帮到你。本文还有配套的精品资源点击获取 在线教育系统需求分析说明书：UML建模与Oracle数据落地实战指南
简介这份在线教育网系统需求分析说明书面向学校信息化建设者、软件工程专业学生及项目开发人员为构建B/S架构的在线教育平台提供完整的需求指导。文档围绕学员管理、网上教学管理与校园信息管理三大模块展开详细梳理了权限设置、角色管理、栏目维护、班级科目创建、教学资料上传下载、在线考试与自动改卷等业务功能并配有UML用例图与参与者描述明确管理员、教师、学员三类角色的行为边界。资源包内含1个doc文档约2.21MB内容涵盖项目背景、用户环境、功能清单与需求分析技术栈涉及.Net Framework 2.0、Oracle 9i及Rational Rose、PowerDesigner建模工具。目前已有1583人学习适合需要撰写需求规格说明书、开展课程设计或搭建在线教育平台的读者参考可帮助快速理解系统功能划分与用例建模思路。1. 在线教育网系统需求分析说明书从一份文档到一套能落地的建模范式做过在线教育平台的人都有一个共识真正拖慢进度的从来不是写代码而是需求阶段没把角色、权限、课程状态机这三件事说清楚。一份合格的在线教育网系统需求分析说明书本质上是把“谁在什么条件下能对哪门课做什么操作”翻译成 B/S 架构下可建模、可验证、可交付的技术契约。它面向的是要交付真实系统的开发团队不是交作业的学生。热搜里 uml 用例图、uml 类图、E-R 图、Oracle 这些词频繁出现恰恰说明大家卡在同一个地方知道要画图但不知道画到什么颗粒度才算够用。这篇笔记就按我实际做项目的顺序把这份说明书从结构、建模、数据设计到评审验收整条链路拆开讲让你拿到就能照着写。2. 需求分析说明书该写哪几块B/S 在线教育系统的文档骨架在线教育系统的需求文档和普通管理系统最大的区别在于它同时存在“内容生产”和“内容消费”两条主线讲师侧要管课程、章节、题库、直播排期学员侧要管选课、学习进度、订单、考试。两条线共用一套用户体系和权限模型所以文档骨架必须先把边界划清楚否则后面 UML 建模会互相打架。2.1 五段式结构从业务目标到验收标准我一般把说明书拆成五段每段都有明确的交付物不写完不进入下一段段落核心内容交付物常见返工点业务概述平台定位、目标用户、核心业务流程业务流程图 角色清单角色漏了助教/运营功能需求按模块拆解功能点用例图 用例规约用例粒度太粗数据需求实体、属性、关系E-R 图 数据字典忽略历史数据非功能需求性能、安全、并发指标表只写“高性能”验收标准每个用例的可测条件验收清单无法量化业务概述这一段很多人写得像宣传文案其实它只需要回答三个问题平台服务谁、他们来干什么、平台靠什么盈利。在线教育场景下角色至少包括学员、讲师、助教、运营、管理员五类少一个后面权限模型就要推倒重来。功能需求按模块拆我习惯分成用户中心、课程管理、学习中心、订单支付、考试测评、直播互动、后台运营七个模块每个模块再往下拆用例。非功能需求是最容易被敷衍的部分。在线教育系统有几个硬指标必须写进文档课程视频并发播放数、直播延迟上限、订单支付成功率、考试提交的幂等性要求。这些指标直接决定后面架构选型和数据库设计不写清楚开发和测试都没有依据。2.2 用例规约怎么写才不会被开发怼用例图只是索引真正让开发能动手的是用例规约。一个完整的用例规约包含用例编号、名称、参与者、前置条件、基本流程、备选流程、后置条件、业务规则。以“学员选课”为例前置条件学员已登录且账号状态正常基本流程进入课程详情 → 校验是否已选 → 校验课程容量 → 生成订单 → 跳转支付备选流程课程已满 → 提示并推荐相似课程重复选课 → 直接进入学习中心后置条件订单记录写入课程容量减一业务规则同一课程不可重复购买未支付订单 30 分钟自动关闭这里有个血泪经验备选流程一定要写全开发写代码时最怕的就是“这种情况怎么办”。你少写一条联调时就多吵一次。业务规则里的数字30 分钟、容量上限必须和运营确认不能自己拍脑袋。2.3 把热搜里的 UML 图落到文档对应位置很多人搜 uml 用例图、uml 类图、uml 中的动态结构图包括哪些其实是想知道每种图放在文档哪个位置。我的对应关系是用例图 → 功能需求章节每个模块一张类图 → 数据需求章节描述实体间静态关系时序图 / 活动图 / 状态图 → 关键流程章节描述动态行为E-R 图 → 数据需求章节和类图互补动态结构图在 UML 里指的就是时序图、协作图、活动图、状态图这四类在线教育系统里最常用的是时序图描述选课、支付、直播推流和状态图描述课程状态、订单状态。状态图尤其重要课程从“草稿→待审核→已上架→已下架”的流转订单从“待支付→已支付→已退款”的流转画清楚能省掉大量沟通成本。3. 用 UML 把在线教育核心流程建模用例图、类图、时序图的画法与参数UML 建模不是画得漂亮就行关键是颗粒度和一致性。我见过太多文档用例图和类图对不上开发照着做发现少字段。这一章按“先静态后动态”的顺序把三类核心图的画法和参数讲透。3.1 用例图角色与用例的边界怎么划在线教育系统的用例图我一般画三张学员视角、讲师视角、管理视角。不画一张大图的原因是角色太多连线会变成蜘蛛网评审时没人看得清。学员视角的核心用例浏览课程、搜索课程、选课下单、支付、观看视频、做练习、参加考试、查看成绩、评价课程、申请退款。讲师视角创建课程、编辑章节、上传视频、组卷、发布考试、查看学员数据、发起直播。管理视角审核课程、管理用户、处理退款、配置轮播、查看报表。画用例图有三个参数要定用例粒度一个用例对应一个完整的用户目标不要拆成“点击按钮”这种操作级。include 和 extend 的使用必须执行的公共步骤用 include如“支付”include“校验订单”可选扩展用 extend如“选课”extend“使用优惠券”。角色继承助教继承讲师的部分权限时用泛化箭头但不要为了省事把管理员和运营合并。注意用例图里不要出现数据库、接口、类这些技术元素它是业务视角的图混入技术元素会让业务方看不懂评审直接卡住。3.2 类图实体、属性、关系的设计参数类图是后面建表的基础属性设计错了数据库就要改。在线教育系统的核心类包括User用户、Student、Teacher、Course课程、Chapter章节、Lesson课时、Order订单、Payment支付、Exam考试、Question题目、AnswerRecord答题记录、Enrollment选课记录。每个类的关键属性// 课程类核心字段设计 public class Course { private Long courseId; // 主键雪花ID private String title; // 课程标题唯一索引 private Long teacherId; // 讲师ID外键 private Integer status; // 状态0草稿 1待审核 2已上架 3已下架 private BigDecimal price; // 价格精度两位小数 private Integer capacity; // 容量上限0表示不限 private Integer enrolledCount; // 已选人数冗余字段 private Date createTime; // 创建时间 private Date updateTime; // 更新时间 }类之间的关系要标清楚Student 和 Course 是多对多通过 Enrollment 关联Course 和 Chapter 是一对多Chapter 和 Lesson 是一对多Order 和 Course 是多对一Exam 和 Question 是多对多通过 ExamQuestion 关联。多重性标注1、0..、1..不能省它直接决定外键建在哪张表。类图里还有一个容易忽略的点抽象类。User 可以设计成抽象类Student 和 Teacher 继承它公共属性用户名、密码、手机号、状态放父类角色特有属性放子类。这样权限校验时统一操作 User 即可。3.3 时序图选课支付和直播推流两条关键链路时序图描述对象间的消息传递顺序在线教育系统里最值得画的两条链路是选课支付和直播推流。选课支付的时序学员 → 课程服务校验课程状态和容量→ 订单服务创建订单→ 支付服务调用支付网关→ 回调订单服务更新订单状态→ 课程服务增加选课记录、容量减一→ 通知学员。这条链路里有两个关键参数订单超时时间一般 30 分钟和支付回调的幂等键用订单号做唯一约束。直播推流的时序讲师端 → 推流服务鉴权、分配推流地址→ 流媒体服务器 → 学员端拉流。这里要标注清楚鉴权 token 的有效期和拉流地址的过期时间一般 token 有效期 2 小时拉流地址 4 小时。画时序图时激活条对象执行操作的时期要画准确它反映了对象的生命周期。消息编号建议加上方便评审时逐条对照。返回消息用虚线箭头异步消息用开放箭头这些细节在软考中级 UML 建模里是考点在实际项目里是沟通效率的保障。4. E-R 图到 Oracle 建表在线教育系统的数据落地UML 类图解决的是业务对象关系E-R 图解决的是数据库落地。两者视角不同类图可以有继承、多态E-R 图必须扁平化成表和字段。在线教育系统数据量增长最快的是学习记录和答题记录设计时就要考虑分区和索引。4.1 从类图到 E-R 图的转换规则转换规则我总结成四条普通类转表属性转字段主键选无业务含义的自增或雪花 ID。一对多关系外键建在多的一方。Course 和 Chapter外键 chapter.course_id。多对多关系拆中间表。Student 和 Course 拆 enrollment 表字段为 student_id、course_id、enroll_time、progress。继承关系两种策略单表继承所有角色一张 user 表加 role 字段或类表继承user 表存公共字段student、teacher 表存特有字段。在线教育系统我推荐类表继承因为讲师和学员的特有字段差异大。E-R 图里要标注清楚主键PK、外键FK、唯一约束UK和索引。课程表的 title 加唯一索引订单表的 order_no 加唯一索引学习记录表的 (student_id, lesson_id) 加联合唯一索引防止重复记录。4.2 Oracle 建表脚本与关键参数Oracle 是在线教育系统常见的选择尤其在中大型机构。建表时几个参数必须显式指定-- 课程表建表脚本 CREATE TABLE t_course ( course_id NUMBER(20) NOT NULL, title VARCHAR2(200) NOT NULL, teacher_id NUMBER(20) NOT NULL, status NUMBER(2) DEFAULT 0 NOT NULL, price NUMBER(10,2) DEFAULT 0 NOT NULL, capacity NUMBER(8) DEFAULT 0 NOT NULL, enrolled_count NUMBER(8) DEFAULT 0 NOT NULL, create_time DATE DEFAULT SYSDATE NOT NULL, update_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT pk_course PRIMARY KEY (course_id), CONSTRAINT uk_course_title UNIQUE (title) ); -- 索引按讲师和状态查询课程列表 CREATE INDEX idx_course_teacher ON t_course(teacher_id, status); -- 注释 COMMENT ON TABLE t_course IS 课程表; COMMENT ON COLUMN t_course.status IS 0草稿 1待审核 2已上架 3已下架;参数说明NUMBER(20) 用于雪花 IDNUMBER(10,2) 用于金额保证两位小数VARCHAR2 用字节长度还是字符长度取决于字符集AL32UTF8 下 VARCHAR2(200) 能存 200 个字符。DATE 类型在 Oracle 里包含时分秒不需要 TIMESTAMP 除非要毫秒精度。分页查询是在线教育系统列表页的高频操作Oracle 12c 之后可以用 OFFSET FETCH-- Oracle 12c 分页 SELECT course_id, title, price FROM t_course WHERE status 2 ORDER BY create_time DESC OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY;12c 之前用 ROWNUM 嵌套写法繁琐且容易出错。如果项目还在用 11g建议封装成存储过程或视图避免每个查询都写嵌套。4.3 学习记录表的分区与索引策略学习记录是在线教育系统增长最快的表一个学员看一节课就产生一条记录日增可能几十万。这张表必须做分区按 create_time 做范围分区每月一个分区CREATE TABLE t_learn_record ( record_id NUMBER(20) NOT NULL, student_id NUMBER(20) NOT NULL, lesson_id NUMBER(20) NOT NULL, course_id NUMBER(20) NOT NULL, progress NUMBER(5,2) DEFAULT 0, last_time DATE, create_time DATE DEFAULT SYSDATE NOT NULL, CONSTRAINT pk_learn_record PRIMARY KEY (record_id, create_time) ) PARTITION BY RANGE (create_time) ( PARTITION p202401 VALUES LESS THAN (TO_DATE(2024-02-01,YYYY-MM-DD)), PARTITION p202402 VALUES LESS THAN (TO_DATE(2024-03-01,YYYY-MM-DD)) );分区键必须包含在主键里这是 Oracle 分区表的硬性要求。查询时带上 create_time 条件才能命中分区裁剪否则全分区扫描。索引建在 (student_id, lesson_id) 上用于查询某个学员某节课的记录。提示Oracle 中 TRUNC(SYSDATE) 常用于按天统计TRUNC(SYSDATE, MM) 按月统计。学习时长统计用 SUM(progress) 配合 GROUP BY 即可但要注意 progress 是百分比还是秒数设计时统一成秒数更灵活。5. 需求评审与避坑在线教育系统文档最容易翻车的五个地方需求评审是文档交付前的最后一道关也是翻车最集中的环节。下面五条是我踩过的坑每条按现象、原因、解决写。5.1 用例图和类图对不上开发照着做发现少字段现象评审时用例图里“学员评价课程”这个用例类图里找不到评价实体开发问评价数据存哪当场卡住。原因用例图和类图分开画画完没有交叉核对。用例图关注行为类图关注数据但每个用例背后都有数据支撑。解决画完类图后逐个用例检查是否有对应实体。评价用例对应 Evaluation 类字段包括 evaluation_id、student_id、course_id、score、content、create_time。建立一张“用例-实体对照表”评审时逐行过。5.2 订单状态机没画支付回调把订单改成错误状态现象支付成功后订单状态变成“已支付”但退款回调又把状态改成“已退款”而实际退款还没到账学员看到状态混乱。原因订单状态流转没有用状态图定义清楚开发各自为政回调逻辑互相覆盖。解决用状态图定义订单全生命周期待支付 → 已支付 → 已退款 / 已关闭。每个状态转换标注触发事件和守卫条件。支付回调只能把“待支付”改成“已支付”退款回调只能把“已支付”改成“已退款”其他转换一律拒绝。状态字段加版本号做乐观锁防止并发覆盖。5.3 课程容量并发扣减超卖现象课程容量 100实际卖出 105 份运营发现后紧急下架。原因需求文档只写了“校验课程容量”没写并发场景下的扣减策略。开发用“先查再改”的写法两个请求同时查到容量剩 1都判断可以选都扣减。解决文档里明确写“容量扣减必须用数据库原子操作”。实现上用UPDATE t_course SET enrolled_count enrolled_count 1 WHERE course_id ? AND enrolled_count capacity根据影响行数判断是否成功。或者用 Redis 预扣减加消息队列异步落库。这个规则必须写进非功能需求章节。5.4 Oracle 监听服务起不来开发环境集体瘫痪现象早上到公司开发环境连不上 Oracle报 ORA-12541 TNS 无监听程序。原因服务器重启后监听服务没自启或者 listener.ora 配置被改。热搜里 oracle 监听服务无法启动是高频问题。解决文档里加一节“环境部署说明”写明监听服务自启配置。Linux 下用lsnrctl start启动检查lsnrctl status。如果是端口被占用netstat -tlnp | grep 1521排查。修改默认监听端口后要同步更新 tnsnames.ora 和客户端的连接配置。这类环境问题写进文档能省掉新成员大量排查时间。5.5 需求文档没写数据权限学员能查到别人成绩现象测试时发现学员 A 通过改 URL 参数能查到学员 B 的考试成绩。原因功能需求只写了“查看成绩”没写数据权限规则。开发只做了功能鉴权是否登录没做数据鉴权只能看自己的。解决文档里每个查询类用例都要加“数据权限”一栏。查看成绩的数据权限规则是“仅本人”查看班级报表的是“仅本班讲师”查看全平台报表的是“管理员”。实现上在 SQL 里强制拼 student_id 条件或者在服务层做统一拦截。这条规则不写等保测评和渗透测试都会挂。6. 让说明书真正被用起来一个可复用的评审清单和迭代习惯文档写完不是终点能被开发、测试、运维持续引用才是。我现在的习惯是给说明书配一份评审清单每次迭代前过一遍迭代后更新一次。清单分四块业务完整性、模型一致性、数据可落地性、非功能可测性。业务完整性检查角色是否覆盖全、每个角色的核心用例是否都有规约、备选流程是否写全。模型一致性检查用例图和类图是否对得上、时序图的消息是否都有对应方法、状态图是否覆盖所有状态转换。数据可落地性检查每个实体是否有建表脚本、索引是否覆盖高频查询、分区策略是否明确。非功能可测性检查每个指标是否有具体数值、是否有对应的测试方法。这份清单我一般做成表格评审时逐项打勾有问题的当场记录负责人和截止时间。迭代结束后把本次新增的用例、实体、状态转换补进文档保持文档和代码同步。文档一旦和代码脱节下次就没人看了。还有一个具体技巧把 E-R 图和建表脚本放在同一章节图下面紧跟 DDL评审时对照着看发现字段对不上当场改。Oracle 的字段类型和 Java 类型映射也列一张表NUMBER(20) 对应 LongNUMBER(10,2) 对应 BigDecimalVARCHAR2 对应 StringDATE 对应 java.util.Date 或 LocalDateTime。这张表能避免很多类型转换的 bug。我自己的教训是早期做项目时觉得需求文档是走形式结果开发到一半发现订单状态没定义清楚返工两周。后来老老实实把状态图、时序图、E-R 图画全评审时拉着开发和测试一起过反而一次通过。文档的价值不在于写得多漂亮而在于每个看图的人都能找到自己需要的答案。希望帮到你。本文还有配套的精品资源点击获取