抖音视频模块：从用例+静态建模推导动态建模的完整过程

动态建模的核心是将用例建模的“业务流程需求”与静态建模的“系统实体结构”结合，描述对象如何按时间/逻辑顺序协作完成业务目标。以下将以抖音视频模块的两个核心用例（浏览推荐视频→顺序图、内容审核→活动图）为例，完整拆解推导过程，每一步都明确依赖的用例/静态建模成果。

前提回顾：用例建模与静态建模核心成果

1. 用例建模核心（关键依据）

核心用例	参与者	基本流程	备选流程
浏览推荐视频	普通用户、推荐引擎	1. 用户刷新视频流；2. 推荐引擎匹配用户偏好；3. 推送视频；4. 记录用户行为；5. 优化推荐模型	1. 无用户偏好→推荐热门视频；2. 视频审核未通过→跳过该视频
内容审核	内容审核员、推荐引擎	1. 视频提交审核；2. AI初审；3. 审核员复审；4. 通过→同步至推荐引擎；5. 驳回→发送整改通知	1. AI初审通过→直接上线；2. AI初审驳回→无需复审

2. 静态建模核心（关键依据）

类类型	类名	核心属性	核心方法
实体类	OrdinaryUser（普通用户）	userId、nickname、preferenceTag（偏好标签）	refreshVideoFeed()（刷新视频流）、viewVideo()（浏览视频）
实体类	Video（视频）	videoId、title、auditStatus、playCount	getVideoInfo()（获取视频信息）
实体类	AuditRecord（审核记录）	auditId、videoId、auditResult、rejectReason	createAuditRecord()（创建审核记录）
控制类	RecommendationManager（推荐管理器）	无	generateVideoFeed()（生成视频流）、updateUserPreference()（更新用户偏好）
控制类	VideoManager（视频管理器）	无	processAuditResult()（处理审核结果）
边界类	InteractionUI（交互界面）	无	showVideo()（展示视频）、showAuditResult()（展示审核结果）
实体类	Auditor（审核员）	auditorId、auditPermission	reviewVideo()（复审视频）、confirmAuditResult()（确认审核结果）

一、推导顺序图（聚焦“浏览推荐视频”用例）

顺序图聚焦时间维度，描述对象间按时间顺序的消息传递，推导步骤如下：

步骤1：确定动态建模的目标场景（依赖用例建模）

• 依据：用例建模中的“浏览推荐视频”核心用例，明确建模目标是“普通用户刷新并浏览推荐视频的交互过程”。
• 排除：暂不覆盖“发布视频”“评论”等无关用例，保证场景聚焦。

步骤2：筛选参与交互的对象（依赖静态建模+用例参与者）

• 从静态建模的类中，筛选出与“浏览推荐视频”直接相关的类（实例化为对象）：
  • 发起者：OrdinaryUser（普通用户对象，对应用例参与者“普通用户”）；
  • 交互入口：InteractionUI（交互界面对象，处理用户与系统的交互）；
  • 核心逻辑协调者：RecommendationManager（推荐管理器对象，对应用例中的“推荐引擎”）；
  • 数据载体：Video（视频对象，推荐的核心内容）；
• 排除：Auditor、AuditRecord等与该用例无关的类，避免冗余。

步骤3：梳理交互时间顺序（依赖用例建模的基本流程）

将用例的“基本流程”拆解为时间轴上的步骤，对应对象的动作：

用例流程 → 时间顺序步骤
1. 用户刷新视频流 → 普通用户发起刷新请求
2. 推荐引擎匹配用户偏好 → 推荐管理器读取用户偏好标签
3. 推送视频 → 推荐管理器筛选视频并返回
4. 用户浏览 → 界面展示视频
5. 记录用户行为 → 推荐管理器更新用户偏好

步骤4：定义对象间的消息传递（依赖静态建模的类方法）

将时间步骤转化为对象的方法调用（消息） ，每个消息对应静态类的方法，确保“方法可追溯、调用有依据”：

时间顺序	发送对象	接收对象	消息（方法调用）	静态建模依据	用例建模依据
1	OrdinaryUser	InteractionUI	refreshVideoFeed(userId)	InteractionUI.showVideo()	用户刷新视频流
2	InteractionUI	RecommendationManager	generateVideoFeed(userId)	RecommendationManager.generateVideoFeed()	推荐引擎匹配偏好
3	RecommendationManager	OrdinaryUser	getUserPreference(userId)	OrdinaryUser.preferenceTag	读取用户偏好
4	OrdinaryUser	RecommendationManager	returnPreference(tagList)	-	反馈偏好数据
5	RecommendationManager	Video	getAvailableVideo(tagList)	Video.getVideoInfo()	筛选匹配视频
6	Video	RecommendationManager	returnVideoList(videoInfoList)	-	返回视频数据
7	RecommendationManager	InteractionUI	pushVideoFeed(videoInfoList)	-	推送视频流
8	InteractionUI	OrdinaryUser	showVideo(videoInfo)	InteractionUI.showVideo()	用户浏览视频
9	OrdinaryUser	RecommendationManager	recordBehavior(userId, videoId, stayTime)	RecommendationManager.updateUserPreference()	记录用户行为
10	RecommendationManager	OrdinaryUser	updatePreferenceTag(userId, newTagList)	-	优化推荐模型

步骤5：补充分支逻辑（依赖用例建模的备选流程）

针对用例的“备选流程”，添加顺序图的分支（条件判断）：

• 分支1：若用户无偏好数据（OrdinaryUser.preferenceTag为空），则RecommendationManager调用Video.getHotVideo()（获取热门视频），替代步骤3-5；
• 分支2：若Video.getAvailableVideo()返回的视频中存在auditStatus=“驳回”的视频，则自动过滤，重新筛选视频。

最终“浏览推荐视频”顺序图（简化示意）

OrdinaryUser → InteractionUI: refreshVideoFeed(1001)  // 用户1001刷新视频流
InteractionUI → RecommendationManager: generateVideoFeed(1001)
RecommendationManager → OrdinaryUser: getUserPreference(1001)
OrdinaryUser → RecommendationManager: returnPreference(["美食", "旅行"])
RecommendationManager → Video: getAvailableVideo(["美食", "旅行"])
Video → RecommendationManager: returnVideoList([{videoId:2001, title:"美食探店"}, ...])
RecommendationManager → InteractionUI: pushVideoFeed([{videoId:2001, ...}])
InteractionUI → OrdinaryUser: showVideo({videoId:2001, ...})
OrdinaryUser → RecommendationManager: recordBehavior(1001, 2001, 30s)
RecommendationManager → OrdinaryUser: updatePreferenceTag(1001, ["美食", "旅行", "探店"])

二、推导活动图（聚焦“内容审核”用例）

活动图聚焦逻辑流程，描述业务步骤的流转（含分支、合并、循环），推导步骤如下：

步骤1：确定动态建模的目标场景（依赖用例建模）

• 依据：用例建模中的“内容审核”核心用例，明确建模目标是“视频从提交审核到最终上线/驳回的流程”。

步骤2：拆解活动节点（依赖用例建模的流程）

将用例的“基本流程+备选流程”拆解为活动节点、判断节点、初始/结束节点：

初始节点 → 提交审核 → AI初审 → 判断：初审是否通过？
  → 是 → 判断：是否需要人工复审？
    → 是 → 审核员复审 → 判断：复审是否通过？
      → 是 → 同步至推荐引擎 → 结束节点（审核通过）
      → 否 → 发送整改通知 → 结束节点（审核驳回）
    → 否 → 同步至推荐引擎 → 结束节点（审核通过）
  → 否 → 发送整改通知 → 结束节点（审核驳回）

步骤3：匹配执行对象（依赖静态建模的类）

为每个活动节点指定静态类的对象，明确“谁来执行该动作”：

活动节点	执行对象	静态建模依据
提交审核	VideoManager	VideoManager.submitVideoForAudit()
AI初审	VideoManager（内置AI审核逻辑）	VideoManager.processAuditResult()
审核员复审	Auditor	Auditor.reviewVideo()
同步至推荐引擎	RecommendationManager	RecommendationManager.addVideoToFeed()
发送整改通知	InteractionUI	InteractionUI.sendRectificationNotice()

步骤4：梳理分支与合并（依赖用例建模的备选流程）

• 分支1：AI初审结果（通过/驳回）→ 对应用例“AI初审通过直接上线，初审驳回无需复审”；
• 分支2：人工复审结果（通过/驳回）→ 对应用例“复审通过同步至推荐引擎，驳回发送整改通知”；
• 合并：所有分支最终指向“审核完成”结束节点。

最终“内容审核”活动图（简化示意）

初始节点
  ↓
VideoManager: 提交视频审核（videoId, userId）
  ↓
VideoManager: AI初审（检测违规内容）
  ↓
判断：AI初审是否通过？
  → 否 → InteractionUI: 发送整改通知（userId, rejectReason）→ 结束节点（审核驳回）
  → 是 → 判断：是否需要人工复审？
    → 否 → RecommendationManager: 同步视频至推荐池 → 结束节点（审核通过）
    → 是 → Auditor: 人工复审视频内容
      ↓
      判断：复审是否通过？
        → 否 → InteractionUI: 发送整改通知（userId, rejectReason）→ 结束节点（审核驳回）
        → 是 → RecommendationManager: 同步视频至推荐池 → 结束节点（审核通过）

三、推导逻辑核心总结

动态建模环节	依赖用例建模的内容	依赖静态建模的内容	核心关联逻辑
场景定义	核心用例（如“浏览推荐视频”）	-	用例是动态建模的“业务目标”，决定建模范围
对象筛选	用例参与者（如普通用户、审核员）	核心类（如OrdinaryUser、Video）	参与者对应静态类的实例，是交互的“主体”
流程梳理	用例的基本/备选流程	-	用例流程是动态建模的“骨架”，决定步骤顺序
消息/动作定义	用例的交互行为（如“刷新视频流”）	类的方法（如refreshVideoFeed()）	用例行为转化为类的方法调用，是交互的“具体操作”
分支/约束	用例的备选流程、前置/后置条件	类间关系（如依赖、关联）	用例约束决定分支逻辑，类间关系限制对象调用权限

闭环逻辑

用例建模回答“系统要做什么、按什么步骤做”→ 静态建模回答“系统由哪些对象组成、对象能做什么”→ 动态建模回答“对象如何按步骤协作完成目标”，三者层层递进，确保动态模型既贴合业务需求，又符合系统结构设计。

四、扩展：动态建模验证静态建模的合理性

推导动态建模的过程，也是对静态建模的“反向验证”：

• 若动态建模中发现某个动作“无对应类的方法”（如“记录用户浏览时长”无对应方法），需补充静态类的方法（如RecommendationManager.addBehaviorRecord()）；
• 若发现对象间“无法调用方法”（如OrdinaryUser无法直接访问Video），需补充类间依赖关系（如OrdinaryUser依赖RecommendationManager，通过其间接访问Video）。

例如：在推导“浏览推荐视频”顺序图时，若发现缺少“记录用户行为”的方法，需在静态建模的RecommendationManager中补充recordUserBehavior()方法，从而完善静态模型。

这体现了建模的“迭代性”：用例→静态→动态→优化静态，最终确保模型的一致性和完整性。