什么是数据流图，为什么它仍然对软件开发有用？
数据流模型 是显示系统如何处理数据的直观方式。 在分析级别，它们应该用于对现有系统中处理数据的方式进行建模。
DeMarco 的《结构化系统分析》一书出版后 ，数据流模型在分析中的应用越来越广泛。它们是从这项工作开发的结构化方法的固有部分。这些模型中使用的符号代表函数处理（圆角矩形）、数据存储（矩形）和函数之间的数据移动（标记箭头）。
为什么 DFD 仍然对软件开发有用？
尽管 面向数据流的建模 被一些软件工程师认为是一种过时的技术，但它仍然是最广泛使用的需求分析符号之一。尽管数据流图 (DFD) 不是 UML 的正式部分，但它们可用于补充 UML 图并提供对系统需求和流程的额外洞察。
数据流模型很有价值，因为跟踪和记录与特定流程相关的数据如何在系统中移动有助于分析师了解正在发生的事情。数据流图的优势在于，与其他一些建模符号不同，它们简单直观。通常可以向可能参与需求分析和验证的潜在系统用户解释它们。
为什么选择 DFD？
DFD 以图形方式表示在系统及其环境之间以及系统组件之间捕获、操作、存储和分发数据的功能或过程。视觉表示使其成为用户和系统设计师之间的良好沟通工具。DFD 的结构允许从广泛的概述开始并将其扩展到详细图表的层次结构。由于以下原因，经常使用 DFD：
- 系统逻辑信息流
- 确定物理系统构建要求
- 符号的简单性
- 建立手动和自动化系统要求
DFD 是一个自上而下的分解过程
数据流建模是一个“自上而下”的过程。首先分析整个采购流程。然后以自上而下的分解方式分析子过程。
DFD 可用于对任何抽象级别的系统或软件进行建模。如前所述，DFD 可以分为代表不断增加的信息流和功能细节的级别。DFD 中的级别数为 0、1、2 或更高。在这里，我们将看到数据流图中的三个主要级别，即 0 级 DFD、1 级 DFD 和 2 级 DFD。
DFD 自顶向下分解过程
上下文图 – DFD 的级别
上下文图（也称为0级DFD），它将整个软件需求表示为一个气泡，输入和输出数据由输入和输出箭头表示。
然后将该系统分解为具有多个气泡的 DFD。然后将每个气泡所代表的系统部分分解并记录到越来越详细的数据流图中。这个过程可以在必要的层次上重复，直到手头的程序被完全理解。
必须保持级别之间的输入和输出数量，这一概念称为 DeMacro 调平。因此，如果气泡“A”有两个输入 X1 和 X2 以及一个输出 Y，那么代表上层 DFD“A”的子级数据流图应该正好有两个外部输入和一个外部输出。
在 1 级 DFD 中，上下文图被分解为多个流程。在这一层中，我们突出了系统的主要功能，并将 0 级 DFD 的高级流程进一步分解为子流程，以表示处理活动的细节。
上下文图（0 级 DFD） ——上下文图 DFD 是表示系统概览及其与“世界”其他部分交互的图表。
1 级数据流图 ——1 级 DFD 通过显示构成整个系统的主要子流程和数据存储，提供了比上下文图更详细的系统视图。
2 级（或更低） ——数据流建模技术的一个主要优势是，现实世界系统的详细复杂性可以通过一种称为“分级”的技术在抽象级别进行管理和建模。任何数据流图的某些元素都可以在层次结构的较低级别分解（“分解”）为更详细的模型
DFD 级别 – 示例– 食品订购系统
0级
它也被称为 上下文图。它被设计成一个抽象视图，将系统显示为单个进程及其与外部实体的关系。
- 上下文图必须适合一页。
- 上下文图中的进程名称应该是信息系统的名称。
- 例如，评分系统、订单处理系统、注册系统。
食品订购系统 — 上下文图 — 0 级 DFD
在 1 级 DFD 中，上下文图被分解为多个流程。在这一层中，我们突出了系统的主要功能，并将 0 级 DFD 的高级流程进一步分解为子流程，以表示处理活动的细节。
级别 1 – 食品订购系统
在 1 级 DFD 中，上下文图被分解为多个流程。在这一层中，我们突出了系统的主要功能，并将 0 级 DFD 的高级流程进一步分解为子流程，以表示处理活动的细节。
1 级 DFD — 食品订购系统示例
如果一个流程在几个外部实体之间有大量数据流链接，我们可以先将该特定流程和关联的外部实体提取到一个类似于上下文图的单独图表中，然后再将流程细化为单独的 DFD 级别；通过这种方式，您可以更轻松地确保它们之间的一致性。
DFD 符号
有 四个基本符号 用于表示数据流图。
过程
一个进程接收输入数据并产生具有不同内容或形式的输出。流程可以简单到收集输入数据并保存在数据库中，也可以复杂到生成包含西北地区所有零售店月销售额的报告。
每个进程都有一个名称来标识它执行的功能。
该名称由一个动词组成，后跟一个单数名词。
例子：
- 申请付款
- 计算佣金
- 验证订单
DFD 表示法
- 圆角矩形代表一个进程
- 进程被赋予 ID 以便于引用
流程示例
数据流
数据流是数据从信息系统的一个部分移动到另一个部分的路径。数据流可以表示单个数据元素，例如客户 ID，也可以表示一组数据元素（或数据结构）。
例子：
- Customer_info（姓氏、名字、SS#、电话号码等）
- Order_info（OrderId、Item#、OrderDate、CustomerID 等）。
数据流示例：
符号
- 带有传入箭头的直线是输入数据流
- 带外向箭头的直线是输出数据流
注意：
因为每个进程都将数据从一种形式更改为另一种形式，所以每个进程符号必须至少有一个数据流进入，一个数据流必须退出。
数据存储
数据流图中使用数据存储或数据存储库来表示系统必须保留数据的情况，因为一个或多个进程需要在以后使用存储的数据。
符号
- 可以将数据写入数据存储区，由外向箭头表示
- 可以从数据存储中读取数据，数据存储由传入箭头表示。
- 例如：库存、应收账款、订单和每日付款。
数据存储示例
注意：
- 数据存储必须通过数据流连接到流程。
- 每个数据存储必须具有至少一个输入数据流和至少一个输出数据流（即使输出数据流是控制或确认消息）。
外部实体
外部实体是向系统提供数据或从系统接收输出的个人、部门、外部组织或其他信息系统。外部实体是信息系统边界之外的组件。它们代表了信息系统如何与外部世界交互。
- 一个矩形代表一个外部实体
- 他们要么提供数据，要么接收数据
- 他们不处理数据
符号
- 客户提交订单，然后从系统收到账单
- 供应商开具发票
外部实体示例
注意：
- 外部实体也被称为终结者，因为它们是数据源或最终目的地。
- 外部实体必须通过数据流连接到流程。
数据流规则
开发 DFD 的规则之一是所有流程都必须以处理步骤开始和结束。这是非常合乎逻辑的，因为数据不能随着处理而自行转换。通过使用拇指规则，可以很容易地识别非法数据流并在 DFD 中纠正它们。
错误/正确描述
一个实体不能在没有进行某些处理的情况下向另一个实体提供数据。
数据不能在未经处理的情况下直接从实体移动到数据故事。
未经处理的数据不能直接从数据存储中移动。
数据不能在未经处理的情况下直接从一个数据存储移动到另一个数据存储。
DFD 中的其他常见错误
当一个处理步骤的输出与其输入不匹配时，会出现第二类 DFD 错误，它们可以分类为：
- 黑洞——一个处理步骤可能有输入流但没有输出流。
- 奇迹——一个处理步骤可能有输出流但没有输入流。
- 灰洞——一个处理步骤的输出可能大于其输入的总和
免费的 UML 工具
DFD 不同表示法
posted on 2022-02-16 15:59 Lynch_Warren 阅读(785) 评论(0) 编辑 收藏 举报
