从用例建模到静态建模

抖音视频相关功能UML建模案例（用例建模→静态建模）

一、前置：抖音视频相关功能用例建模结果

用例建模核心目标：明确抖音视频全生命周期（创作-审核-分发-消费-互动）中，各参与者与系统的交互关系，聚焦“视频相关”核心功能，排除直播、电商等非相关模块。

1.1 核心参与者识别

基于“谁与系统交互”“谁触发视频相关流程”“谁需系统提供视频服务”三大原则识别，结果如下：

• 普通用户：抖音视频的核心创作主体（发布视频）与消费主体（浏览、互动视频）；

• 内容审核员：负责视频合规性审核（平台强制要求，保障内容安全）；

• 推荐引擎（系统角色）：被动响应交互，根据用户行为推送视频，是视频分发的核心载体。

1.2 核心用例及关系

围绕“视频创作-审核-分发-消费-互动”全流程筛选，排除非核心用例（如用户注册、修改资料），明确用例间包含、扩展关系，结果如下：

用例名称	关联参与者	用例关系	核心描述
发布视频	普通用户	包含“编辑视频”“添加配乐/特效”“添加标签”用例	用户拍摄或上传本地视频，经编辑后提交系统
内容审核	内容审核员、推荐引擎	扩展“整改通知”用例（审核不通过时触发）	审核员或AI对视频进行合规性核查，通过后同步至推荐引擎
浏览推荐视频	普通用户、推荐引擎	无	用户刷新视频流，推荐引擎推送匹配的视频内容
视频互动（点赞/评论/转发）	普通用户	三者为并列用例，无直接关系	用户对浏览的视频进行点赞、发布评论或转发至其他平台
管理个人视频	普通用户	包含“删除视频”“修改视频描述”用例	用户对自己发布的视频进行编辑或删除操作

1.3 用例图核心结构（简化）

普通用户 → 发布视频、浏览推荐视频、视频互动、管理个人视频；内容审核员 → 内容审核；推荐引擎 ↔ 内容审核、浏览推荐视频；发布视频 <<包含>> 编辑视频；内容审核 <<扩展>> 整改通知。

二、从用例建模推导静态模型的完整过程

静态建模核心是构建类图，描述系统的静态结构（类、属性、方法、类间关系）。推导逻辑：用例参与者/交互行为 → 提取核心实体 → 筛选并定义类 → 分配属性与方法 → 梳理类间关系，逐步拆解如下：

2.1 第一步：从用例中提取核心实体（候选类）

采用“名词提取法”，从用例名称、用例描述、参与者中提取关键名词，这些名词是类的核心来源，提取结果如下：

• 从参与者提取：普通用户、内容审核员；

• 从用例及描述提取：视频、配乐、特效、标签、评论、点赞记录、转发记录、审核记录、整改通知、推荐引擎；

• 从交互场景提取：视频流（用户浏览的内容载体）。

2.2 第二步：筛选与优化候选类（确定核心类）

遵循“单一职责原则”“排除冗余概念”“合并相似实体”的筛选规则，对候选类优化，最终确定6个核心类，筛选逻辑如下：

候选类	筛选逻辑（保留/剔除/合并）	最终核心类	类类型（实体类/控制类/边界类）
普通用户、内容审核员	均为“系统使用者”，可抽象为父类“用户”，通过属性区分角色	用户（User）	实体类（描述用户核心信息）
视频、配乐、特效、标签	配乐、特效、标签是视频的附属属性，不具备独立业务职责，无需单独作为类，合并为视频的属性	视频（Video）	实体类（描述视频核心信息）
评论、点赞记录、转发记录	均为用户与视频的互动产物，具备独立属性（如评论内容、点赞时间）和业务意义，保留为独立类	评论（Comment）、互动记录（InteractionRecord）	实体类（描述互动相关信息）
审核记录、整改通知	整改通知是审核记录的附属信息，合并为“审核记录”，用属性区分审核结果	审核记录（AuditRecord）	实体类（描述审核相关信息）
推荐引擎、视频流	推荐引擎负责“推送视频”的核心逻辑，视频流是推送结果的载体，合并为控制类“推荐管理器”	推荐管理器（RecommendationManager）	控制类（协调视频推送流程）
无	补充控制类：需协调“发布视频-审核-推送”全流程，新增“视频管理器”	视频管理器（VideoManager）	控制类（协调视频发布、审核流程）

2.3 第三步：定义类的属性与方法（基于用例职责）

属性：描述类的状态，从用例描述中提取“需要记录的信息”；方法：描述类的行为，对应用例中的交互动作，确保“每个方法都有明确的用例支撑”，具体定义如下：

2.3.1 实体类

类名	核心属性（来源：用例描述中的关键信息）	核心方法（来源：用例中的交互行为）
User（用户）	用户ID、昵称、头像URL、角色（普通用户/审核员）、注册时间	publishVideo()（发布视频，支撑“发布视频”用例）、interactWithVideo()（视频互动，支撑“视频互动”用例）、manageMyVideo()（管理个人视频，支撑“管理个人视频”用例）
Video（视频）	视频ID、标题、描述、时长、发布时间、视频URL、标签列表、配乐ID、审核状态（待审核/通过/驳回）、播放量	editVideo()（编辑视频，支撑“发布视频”包含用例）、deleteVideo()（删除视频，支撑“管理个人视频”包含用例）、updateDescription()（修改描述，支撑“管理个人视频”包含用例）
Comment（评论）	评论ID、视频ID、用户ID、评论内容、发布时间、点赞数	addComment()（发布评论，支撑“视频互动”用例）、deleteComment()（删除评论，支撑用户自主管理评论场景）
InteractionRecord（互动记录）	记录ID、视频ID、用户ID、互动类型（点赞/转发）、互动时间、转发平台（仅转发时存在）	addLikeRecord()（添加点赞记录）、addShareRecord()（添加转发记录），均支撑“视频互动”用例
AuditRecord（审核记录）	审核ID、视频ID、审核员ID、审核时间、审核结果（通过/驳回）、驳回原因、整改建议	createAuditRecord()（创建审核记录，支撑“内容审核”用例）、sendRectificationNotice()（发送整改通知，支撑“内容审核”扩展用例）

2.3.2 控制类

类名	核心属性（控制类无状态属性，仅协调逻辑）	核心方法（对应用例中的流程协调动作）
VideoManager（视频管理器）	无	submitVideoForAudit()（提交视频审核，衔接“发布视频”与“内容审核”用例）、processAuditResult()（处理审核结果，更新视频审核状态）
RecommendationManager（推荐管理器）	无	generateVideoFeed()（生成视频流，支撑“浏览推荐视频”用例）、pushVideo()（推送视频至用户）、updateUserPreference()（根据用户互动更新偏好，优化推荐逻辑）

2.4 第四步：梳理类间关系（基于用例交互逻辑）

类间关系（继承、关联、依赖）的核心依据：用例中参与者与用例、用例与用例的交互关系，具体推导如下：

• 继承关系：User类是抽象父类，普通用户（OrdinaryUser）和审核员（Auditor）是其子类。推导逻辑：两者均具备User的核心属性（用户ID、昵称）和基础行为（登录），但有特有行为（审核员有auditVideo()方法，普通用户无），符合“泛化-特化”关系。

• 关联关系： User与Video：一对多。推导逻辑：一个用户可发布多个视频（支撑“发布视频”用例），一个视频仅属于一个用户；

• User与Comment：一对多。推导逻辑：一个用户可发布多条评论（支撑“视频互动”用例），一条评论仅属于一个用户；

• Video与Comment：一对多。推导逻辑：一个视频可有多条评论，一条评论仅对应一个视频；

• Video与AuditRecord：一对一。推导逻辑：一个视频仅需一次核心审核（支撑“内容审核”用例），一条审核记录仅对应一个视频。

依赖关系： VideoManager依赖Video、AuditRecord。推导逻辑：VideoManager的submitVideoForAudit()方法需调用Video的信息和AuditRecord的创建方法，完成审核提交；

RecommendationManager依赖Video、User。推导逻辑：生成视频流需获取Video的信息，推送视频需匹配User的偏好（基于User的互动记录）；

User依赖RecommendationManager。推导逻辑：用户浏览推荐视频（支撑“浏览推荐视频”用例）需调用RecommendationManager的generateVideoFeed()方法。

2.5 最终静态模型（类图核心结构）

简化类图示意（核心关系与核心属性/方法）：

// 继承关系 OrdinaryUser -|> User Auditor -|> User // 关联关系 User "1" -- "*" Video （一对多：用户-视频） User "1" -- "*" Comment （一对多：用户-评论） Video "1" -- "*" Comment （一对多：视频-评论） Video "1" -- "1" AuditRecord （一对一：视频-审核记录） // 依赖关系 VideoManager ..> Video VideoManager ..> AuditRecord RecommendationManager ..> Video RecommendationManager ..> User User ..> RecommendationManager // 核心类属性（简化） User: userId, nickname, role; publishVideo(), interactWithVideo() Video: videoId, title, auditStatus; editVideo(), deleteVideo() AuditRecord: auditId, auditResult, rejectReason; createAuditRecord() VideoManager: submitVideoForAudit(), processAuditResult() RecommendationManager: generateVideoFeed(), pushVideo()

三、用例建模→静态建模的核心逻辑总结

1. 参与者→类的推导：用例中的参与者（普通用户、审核员）直接对应静态模型中的“用户类”，并通过属性区分角色，参与者的行为（发布、审核）转化为类的方法；

2. 用例行为→类的方法推导：每个用例的核心交互动作（如“发布视频”“审核视频”），直接转化为对应类的方法（如User.publishVideo()、Auditor.auditVideo()），确保方法有明确的业务支撑；

3. 用例信息→类的属性推导：用例描述中需要“记录的关键信息”（如视频的标题、审核结果），转化为对应类的属性（如Video.title、AuditRecord.auditResult）；

4. 用例关系→类间关系推导：用例的包含/扩展关系，转化为类间的依赖关系（如“发布视频”包含“编辑视频”，转化为VideoManager依赖Video）；用例中参与者与用例的关联，转化为类间的关联关系（如用户发布视频，转化为User与Video的一对多关系）。

整体逻辑闭环：从“谁用系统做什么”（用例建模），提炼“系统由哪些核心实体组成”（静态建模的类），再明确“实体如何协作完成用例动作”（类的方法与关系），确保静态模型完全贴合视频相关业务需求，且每一个设计都可追溯至用例建模结果。