Visual Paradigm Desktop | 
Visual Paradigm Online
创建数据流图（DFD）是系统分析中的一个重要里程碑。它描绘了数据在系统中的流动，定义了信息如何被处理、存储和传输。然而，一个看起来视觉上美观的图表并不一定在功能上准确。验证是关键阶段，您需要确认该图表正确地反映了系统需求，且没有逻辑错误。此过程确保数据流一致，处理过程平衡，并且结构支持预期的业务逻辑。
验证不是单一的动作，而是一次有纪律的审查。它需要采用系统化的方法，将每个元素与既定规则进行核对。通过遵循结构化的审查流程，您可以消除歧义，确保图表成为开发和利益相关者沟通的可靠蓝图。本指南概述了有效验证您DFD所需的一系列全面步骤，确保在整个系统设计过程中保持准确性和一致性。
在深入具体步骤之前，理解验证在系统设计背景下的作用至关重要。验证的问题是：“我们是否在正确地构建产品？”而确认的问题是：“我们是否在构建正确的产品？”在DFD的背景下，验证弥合了抽象需求与具体系统行为之间的差距。
经过验证的DFD可确保：
跳过此阶段通常会导致开发阶段出现代价高昂的返工。一旦开始编写代码，诸如缺失数据流或未定义数据存储等问题将难以修复。严格的审查流程可及早降低这些风险。
在开始正式审查之前，请确保图表已准备好接受审查。杂乱或组织不善的图表会使验证变得困难。请使用以下检查清单来准备您的工作：
上下文图是抽象层次最高的图表。它将系统表示为一个单一的处理过程，并展示其与外部实体的交互。这是验证的第一道防线。
外部实体代表系统边界之外的数据源或目的地。确保显示的每个实体都是必要且明确定义的。请提出以下问题：
代表系统的单一过程必须包含所有内部逻辑。验证是否有任何数据流在未经过此过程的情况下跨越边界。如果数据从一个外部实体直接流向另一个外部实体而未进入系统，则不应在上下文图中显示，因为它超出了范围。
检查与中心过程相连的每一条箭头。每个输入都必须有相应的输出或存储操作。如果数据流进入系统但没有数据流出，可能表明存在一个“黑洞”过程，即数据无故消失。
0级DFD将上下文图中的单一过程分解为主要子系统。此处最关键的规则是平衡性。父过程的输入和输出必须与子过程的输入和输出完全匹配。
对于进入上下文图过程的每一个数据流，都必须有相应的数据流进入0级图。输出也同理。这被称为数据守恒。如果上下文图显示“客户订单”进入系统，那么0级图必须显示“客户订单”至少进入一个主要过程。
0级通常包含3到7个过程。如果超过7个，该图可能过于复杂，难以用单一视图呈现。如果少于3个，可能需要进一步分解。确保每个过程都是独立的，并执行单一的逻辑功能。
检查0级中的每个数据存储是否必要。只有当数据需要被保留以供后续使用时，数据存储才应存在。确保流入和流出存储的数据流标签正确。数据存储不应直接连接到外部实体；所有数据都必须经过一个过程。
N级图对0级中识别出的特定过程提供更详细的说明。此级别的验证重点在于与父过程的一致性。
与0级类似，父过程的输入和输出必须与子过程的总输入和输出相匹配。如果在0级图中，过程1.0接收“登录数据”并输出“访问令牌”，那么1.0过程的1级分解也必须接收“登录数据”并生成“访问令牌”。
确保分解是合理的。子图是否解释了如何父过程是如何工作的？避免在子图中引入父图中未暗示的新外部实体或数据存储。如果引入新的数据存储，必须有保留数据的需求作为依据。
子图中数据流的标签必须与父图中的标签一致（如适用）。如果在子图中对某一流进行了细化（例如，“数据”变为“用户数据”），该变化应与数据字典保持一致。此处的模糊性会在实施过程中造成混淆。
存在一些特定的结构异常，表明DFD设计中存在错误。这些常见模式必须在验证过程中被识别并纠正。
黑洞过程是指有输入但无输出的过程。数据进入该过程后便消失了。这通常表明缺少输出流或过程定义不完整。每个过程都必须产生某种结果，无论是要存储的数据、要发送到其他地方的数据，还是决策结果。
奇迹过程是指有输出但无输入的过程。它从无到有地创造数据。这在系统设计中在逻辑上是不可能的。每个输出都必须由输入数据生成，或从存储的数据中推导出来。
当输入在逻辑上与输出不匹配时，就会出现灰洞。例如，如果输入是“客户地址”，而输出是“付款详情”，该过程不仅执行了转换，还生成了无法从输入中推导出的数据。这表明存在缺失的数据流或缺失的数据存储。
确保数据流不会直接从外部实体流向数据存储。所有进入或离开存储的数据都必须经过一个过程。这可以确保在存储之前应用数据完整性规则和业务逻辑。
在审查过程中可将此表作为快速参考。它总结了关键规则以及每个元素所需的特定检查。
| 元素 | 验证规则 | 常见错误 |
|---|---|---|
| 过程 | 必须至少有一个输入和一个输出 | 黑洞或奇迹过程 |
| 数据存储 | 必须连接到过程，而不是实体 | 实体到存储的直接流 |
| 数据流 | 必须使用名词短语进行标注 | 动词标签或缺失标签 |
| 外部实体 | 必须位于系统边界之外 | 实体位于系统边界内 |
| 一致性 | 父级和子级的输入/输出必须匹配 | 数据流不平衡 |
| 分解 | 子级必须解释“如何”，而不是“为什么” | 添加不在范围内的逻辑 |
验证不仅仅是技术检查；它也是一种沟通工具。技术规则满足后，必须由利益相关者审查图表，以确保其满足业务需求。
不要孤立地展示图表。准备一个讲解流程，解释数据的流动。提供某些数据存储存在的原因以及各过程之间如何交互的背景信息。确保所有利益相关者都能访问数据字典以理解术语。
鼓励利益相关者质疑数据流。提出具体问题，例如：
记录所有反馈和建议的变更。如果利益相关者建议新增数据流，在接受前需根据平衡规则进行验证。同时更新图表和数据字典以保持同步。版本管理至关重要；在每次评审周期中保留图表状态的记录。
验证很少是一次性事件。随着需求的演变，DFD也必须随之更新。本节介绍如何在项目生命周期中管理变更。
当有变更请求时，分析其对整个层级的影响。如果一级流程发生变化，是否会影响零级？是否需要新增数据存储？是否会影响共享相同数据流的其他流程？进行此类影响分析可防止连锁错误。
保持图表修订的清晰历史记录。使用版本号（例如 v1.0、v1.1）和修订日期。这使团队能够追踪系统设计的演进过程，并在必要时回滚变更。虽然不需要特定工具，但文件命名需遵循严谨的规范。
实施变更后，需再次运行验证流程。不要假设微小变更不会破坏整体完整性。重新检查平衡规则、命名规范和结构完整性。有时一个微小的添加可能会破坏之前已验证图表的平衡性。
数据字典是DFD的支柱。它定义了每个数据元素的结构。验证必须从视觉图表延伸到文本定义。
确保图表中的数据流标签与字典条目完全一致。如果图表中写的是“Invoice ID”，而字典中写的是“Invoice Identifier”，这种不一致在数据库设计阶段可能造成混淆。应在所有文档中统一术语。
检查每个数据存储在字典中是否都有明确定义的结构。列出属性、数据类型和关键约束。如果数据存储在DFD中被引用但字典中没有条目，设计就是不完整的。这种遗漏通常会导致后期出现数据库错误。
验证图表中隐含的数据类型是否符合业务规则。例如，如果一个数据流代表“出生日期”，在字典中就不应将其视为文本字符串，而应使用日期格式。这种细节确保技术实现与概念设计保持一致。
即使经验丰富的分析师在验证过程中也会遇到特定陷阱。了解这些常见陷阱有助于更有效地完成评审。
验证完成后，必须对文档进行定稿，以便移交给开发团队。这包括整理图表、数据字典和验证报告。
将所有 0 层图表、N 层图表和上下文图整合到一个包中。确保层级关系清晰标注，以便开发人员能够追踪分解过程。将数据字典作为配套文档一并包含。
创建验证过程的摘要报告。列出审查过程中发现的问题及其解决方式。该文档作为设计已通过审查的证据。同时为未来可能未参与初始审查的维护人员提供背景信息。
定义移交已验证 DFD 的流程。应包括一次向开发团队讲解设计的会议。解答关于模糊数据流或复杂数据存储的任何疑问。确保团队理解 DFD 是数据需求的唯一真实来源。
工作不会在验证后结束。随着系统的发展，图表必须保持准确。应建立未来变更的治理流程。
通过遵循这些验证步骤，可以确保您的数据流图在整个系统生命周期中都具备稳健性、准确性和实用性。这种规范性减少了歧义，防止了昂贵的错误，并为成功的系统开发奠定了坚实基础。