4、需求分析建模：用例模型、数据流图（DFD）、实体关系图（ERD）、状态转换图、类图等建模工具的使用方法
需求分析建模是系统分析师将用户模糊的期望转化为可验证、可追踪、可设计的系统规约的核心手段。面对复杂业务，单一视图无法完整描述系统全貌——用例模型回答“系统为谁做什么”，数据流图回答“数据如何流动与加工”，实体关系图回答“业务对象如何关联”，状态转换图回答“关键对象如何随事件变迁”，类图则回答“面向对象设计中的静态结构”。本章将围绕这五种主流建模工具，从核心原理、建模步骤、案例拆解到常见误区，帮助您在实际项目中灵活选用并组合使用。
4.1 用例模型：定义系统边界与价值
4.1.1 核心原理
用例模型由 Ivar Jacobson 提出，强调从参与者（Actor）视角描述系统提供的可观测价值。一个用例代表参与者与系统之间的一次完整交互，其核心要素包括：参与者（人、外部系统或设备）、用例（功能单元）、关系（包含 include、扩展 extend、泛化 generalization）。用例模型的价值在于：它不关心内部实现，只关注“谁”通过系统获得“什么结果”，从而帮助分析师与业务方在功能范围上达成共识。
4.1.2 建模步骤
- 识别参与者：列出所有与系统交互的外部角色，包括主要参与者（直接使用系统）和次要参与者（支撑系统运行，如支付网关、短信服务）。
- 识别用户目标：针对每个参与者，询问“您希望通过系统完成什么目标”，每个目标对应一个用例。
- 绘制用例图：用椭圆表示用例，火柴人表示参与者，连线表示关联关系。
- 编写用例规约：对每个用例补充前置条件、基本流程、备选流程、异常流程、后置条件。
- 评审与确认：与业务方逐条确认用例清单，确保无遗漏、无冗余。
4.1.3 案例拆解：电商订单系统的用例建模
某电商平台需要重构订单模块，业务方最初只提出“用户能下单、能退款”。分析师通过访谈发现：参与者包括顾客、客服、运营管理员、支付网关、库存系统；用例包括“创建订单”“取消订单”“申请退款”“审核退款”“查询订单状态”“超时自动关闭订单”等。其中“取消订单”与“申请退款”存在扩展关系——当订单已支付时，取消订单扩展出退款流程。通过用例图，业务方发现遗漏了“客服代客下单”场景，及时补充了需求。
4.1.4 常见误区
- 用例过细：将“输入用户名”“点击登录按钮”等操作步骤当作用例，导致用例图退化为流程图。
- 忽略次要参与者：只画了人类用户，遗漏外部系统接口，导致集成需求缺失。
- 用例间关系滥用：随意使用 include/extend，造成模型混乱。include 用于公共步骤抽取，extend 用于可选或异常分支。
4.2 数据流图（DFD）：透视数据流动与加工
4.2.1 核心原理
DFD 是结构化分析与结构化设计方法的核心工具，用数据流将外部实体、加工（Process）、数据存储（Data Store）连接起来，描述数据从输入到输出的变换过程。DFD 采用分层建模：顶层图（上下文图）只画一个加工代表整个系统；0 层图分解出主要子系统；1 层图继续细化每个加工。DFD 强调“数据”而非“控制”，适合业务流程清晰、数据密集型系统的需求分析。
4.2.2 建模步骤
- 绘制上下文图：确定系统边界，画出所有外部实体及与系统的数据流。
- 识别主要加工：将系统按业务功能分解为 3-7 个核心加工。
- 定义数据存储：识别需要持久化的数据集合，如“订单表”“用户表”。
- 连接数据流：标注数据流名称，确保每条数据流有来源和去向。
- 逐层细化：对复杂加工继续分解，直到每个加工逻辑足够清晰。
- 平衡检查：父图与子图的输入/输出数据流必须保持一致。
4.2.3 案例拆解：银行转账系统的 DFD 建模
某银行核心系统升级，需要梳理转账流程。上下文图中，外部实体包括柜员、客户、风控系统、会计系统。0 层图分解为“验证账户”“执行转账”“记录流水”“通知结果”四个加工。在细化“执行转账”时，分析师发现需要同时更新“账户余额表”和“交易流水表”，且必须保证事务一致性。通过 DFD 的逐层分解，开发团队明确了数据存储的读写顺序，为后续数据库设计提供了依据。
| DFD 元素 | 符号 | 说明 | 示例 |
|---|---|---|---|
| 外部实体 | 矩形 | 系统外的人或系统 | 客户、银行接口 |
| 加工 | 圆角矩形/圆形 | 数据变换处理 | 验证密码、计算利息 |
| 数据流 | 箭头 | 数据的流动方向 | 转账请求、余额信息 |
| 数据存储 | 开口矩形/双线 | 静态数据集合 | 账户表、日志表 |
4.2.4 常见误区
- 把控制流当数据流：如“启动按钮”“超时信号”是控制事件，不应出现在 DFD 中。
- 加工粒度过粗或过细：一个加工应能在一页内描述清楚，过细则失去抽象意义。
- 忽略数据字典：只画图不定义数据流的具体结构，导致后续设计无法落地。
4.3 实体关系图（ERD）：固化业务数据规则
4.3.1 核心原理
ERD 由 Peter Chen 于 1976 年提出，用于描述业务领域中的实体、属性及实体间关系。ERD 的核心价值在于：将业务规则转化为数据约束，例如“一个客户可以拥有多个订单”“一个订单必须属于一个客户”。ERD 是数据库逻辑设计的直接输入，也是业务人员与技术人员沟通数据需求的语言。
4.3.2 建模步骤
- 识别实体：名词分析法——从需求文档中提取名词，区分实体（有独立存在意义）与属性（描述实体的特征）。
- 定义属性：为每个实体列出关键属性，并标识主键（唯一标识）。
- 确定关系：分析实体间的业务关联，标注基数（1:1、1:N、M:N）。
- 绘制 ERD：使用 Crow's Foot 或 UML 表示法绘制。
- 规范化检查：消除冗余、确保每个属性依赖于主键。
4.3.3 案例拆解：在线教育平台的 ERD 设计
某在线教育平台需要设计课程订阅模块。初步识别出实体：用户、课程、订单、学习记录。分析关系：用户与订单是 1:N；订单与课程是 M:N（一个订单可包含多个课程，一个课程可被多个订单购买），因此引入中间实体“订单明细”。进一步发现“学习记录”依赖于用户和课程，且记录学习进度、最后学习时间等属性。通过 ERD，团队明确了主外键关系，避免了后续开发中数据不一致的问题。
4.3.4 常见误区
- 实体与属性混淆：将“地址”作为用户属性，但若需要统计不同城市的用户分布，地址应独立为实体。
- 忽略关系上的属性：如“订单与课程”的关系上应有“购买数量”“单价”，必须通过中间实体表达。
- 过度设计：为追求范式化而拆分过多实体，导致查询性能下降。需在规范与性能间平衡。
4.4 状态转换图（STD）：刻画对象生命周期
4.4.1 核心原理
状态转换图描述单个对象（如订单、工单、审批流）在其生命周期内，因事件触发而发生的状态迁移。STD 包含四个要素：状态（对象在某一时刻满足的条件）、事件（触发迁移的外部或内部信号）、动作（迁移时执行的操作）、迁移（状态间的转换路径）。STD 特别适合实时系统、工作流系统、协议处理等对时序敏感的场景。
4.4.2 建模步骤
- 确定对象：选择生命周期复杂、状态丰富的核心业务对象。
- 列出所有状态：包括初始状态、中间状态、终止状态。
- 识别触发事件：用户操作、定时器、外部系统消息等。
- 绘制状态图：用圆角矩形表示状态，箭头表示迁移，标注事件/动作。
- 验证完整性：检查每个状态是否有出口，每个事件是否有对应迁移。
4.4.3 案例拆解：订单状态机设计
电商订单的状态包括：待支付、已支付、已发货、已签收、已取消、退款中、已退款。事件包括：用户支付、商家发货、用户确认收货、用户申请退款、系统超时关闭。通过 STD，分析师发现“已发货”状态下用户不能直接取消订单，只能申请退款，且退款需经过审核。这一规则在需求评审时被业务方确认，避免了后续开发中的逻辑漏洞。
| 当前状态 | 触发事件 | 动作 | 下一状态 |
|---|---|---|---|
| 待支付 | 用户支付 | 扣减库存、生成物流单 | 已支付 |
| 待支付 | 超时未支付 | 释放库存 | 已取消 |
| 已支付 | 商家发货 | 通知用户 | 已发货 |
| 已发货 | 用户确认收货 | 完成交易 | 已签收 |
| 已支付/已发货 | 用户申请退款 | 进入审核流程 | 退款中 |
4.4.4 常见误区
- 状态与动作混淆：“正在发送短信”是动作而非状态，状态应描述对象所处的稳定阶段。
- 缺少初始/终止状态：导致对象生命周期不完整。
- 事件与动作混写：迁移标签应写“事件[条件]/动作”，如“支付成功/扣减库存”。
4.5 类图：面向对象分析的静态骨架
4.5.1 核心原理
类图是 UML 中最常用的静态结构图，展示系统中的类、接口、属性、方法及类间关系（关联、聚合、组合、继承、实现）。在需求分析阶段，类图用于建立问题域的领域模型，帮助分析师与开发团队对齐业务概念。类图与 ERD 的区别在于：ERD 关注数据持久化结构，类图关注对象职责与行为。
4.5.2 建模步骤
- 收集业务概念：从用例规约和业务文档中提取名词。
- 筛选候选类：排除冗余、模糊、无属性的名词。
- 定义属性与方法：属性描述对象特征，方法描述对象职责。
- 识别类间关系：关联（has-a）、继承（is-a）、依赖（uses）。
- 绘制类图：使用 UML 标准符号。
4.5.3 案例拆解：医院挂号系统的领域类图
从需求中提取概念：患者、医生、科室、挂号单、排班。分析关系：科室与医生是 1:N 聚合；医生与排班是 1:N；挂号单关联患者、排班和医生。通过类图，团队发现“挂号单”需要同时记录“挂号时间”“就诊序号”“状态”等属性，且“医生”和“患者”都继承自“人员”基类（共享姓名、联系方式）。这一模型直接指导了后续的代码设计。
4.5.4 常见误区
- 类图过度复杂：将实现细节（如数据库连接、工具类）也画入分析类图。
- 关系语义错误：混淆聚合（整体与部分可分离）与组合（部分不能独立存在）。例如“订单”与“订单明细”是组合关系，而“医生”与“科室”是聚合关系。
- 缺少多重性标注：不标注 1、*、0..1 等基数，导致设计歧义。
4.6 五种建模工具的综合应用策略
4.6.1 工具选择矩阵
| 建模场景 | 首选工具 | 辅助工具 | 理由 |
|---|---|---|---|
| 定义系统功能边界 | 用例模型 | DFD（上下文图） | 用例聚焦用户目标，DFD 补充数据边界 |
| 梳理业务流程 | DFD | 用例规约 | DFD 展示数据流动，用例规约补充业务规则 |
| 设计数据库结构 | ERD | 类图 | ERD 直接映射表结构，类图补充行为 |
| 描述对象生命周期 | STD | 用例（异常流程） | STD 覆盖所有状态路径，用例补充触发场景 |
| 面向对象设计 | 类图 | ERD、STD | 类图定义结构，ERD 映射持久化，STD 映射状态 |
4.6.2 综合案例：物流跟踪系统的多视图建模
某物流公司需要开发包裹跟踪系统。分析师采用以下组合策略：
- 用例模型：识别参与者（寄件人、收件人、快递员、客服），用例包括“创建运单”“扫描揽收”“更新轨迹”“查询物流”“异常上报”。
- DFD：绘制 0 层图，展示“运单管理”“轨迹采集”“查询服务”“异常处理”四个加工及数据存储（运单表、轨迹表）。
- ERD：设计运单、轨迹、客户、快递员四张核心表，明确运单与轨迹 1:N、运单与客户 N:1 关系。
- STD：定义运单状态（待揽收、运输中、派送中、已签收、异常），事件（揽收扫描、到达、派件、签收、异常上报）。
- 类图：设计运单类、轨迹类、客户类，运单类包含状态属性和更新轨迹方法。
通过多视图交叉验证，团队发现：用例中“查询物流”需要支持按时间筛选，但 ERD 中轨迹表未设计“时间索引”；STD 中“异常”状态未定义“异常类型”属性。这些问题在需求阶段被及时修正，避免了开发返工。
4.6.3 建模工具使用总结
- 需求分析初期：优先使用用例模型和 DFD 上下文图，快速划定系统边界。
- 需求细化阶段：使用 DFD 分层、ERD、STD 深入描述流程、数据和状态。
- 需求确认阶段：用类图验证面向对象设计的可行性，并反向检查用例的完整性。
- 持续迭代：所有模型应随需求变更同步更新，保持“单一事实来源”。