数据流图(DFD)提供了系统内信息流(即数据流)的可视化表示。通过绘制数据流程图，您可以了解由参与系统流程的人员提供并交付给他们的信息、完成流程所需的信息以及需要存储和访问的信息。本文以一个订餐系统为例，对数据流图(DFD)进行了描述和说明。
食品订购系统示例
上下文
上下文关系图是只显示顶层的数据流关系图，也称为0级。在这个层次上，只有一个可见的流程节点，它代表了一个完整系统的功能，包括它如何与外部实体交互。上下文关系图的一些好处是:
- 显示系统边界的概述
- 使用简单的符号不需要任何技术知识
- 简单的绘制，修改和阐述作为其有限的表示法
下图显示了为食品订购系统绘制的上下文数据流程图。它包含一个表示要建模的系统的流程(形状)，在本例中是“食品订购系统”。它还显示将与系统交互的参与者(称为外部实体)。在本例中，供应商、厨房、经理和客户是将与系统交互的实体。在流程和外部实体之间有数据流(连接器)，表明实体和系统之间存在信息交换。
上下文DFD是数据流模型的入口。它只包含一个进程，并且不显示任何数据存储。
1级过程
下图显示了第一级DFD，它是在DFD上下文中显示的食品订购系统流程的分解(即分解)。通读这张图，然后我们将介绍一些基于这张图的关键概念。
食品订单系统数据流图示例包含三个流程、四个外部实体和两个数据存储。
根据图表，我们知道客户可以下订单。订单食品流程接收订单，将其转发到厨房，将其存储在订单数据存储中，并将更新后的库存详细信息存储在库存数据存储中。该流程还向客户交付账单。
经理可以通过Generate Reports流程接收报告，该流程分别从库存数据存储和订单数据存储中获取库存细节和订单。
经理还可以通过提供库存订单来启动订单库存流程。流程将库存订单转发给供应商，并将更新后的库存详细信息存储在库存数据存储中。
数据流程图提示和注意事项
提示
- 过程标签应该是动词短语;数据存储由名词表示
- 数据存储必须至少与一个进程相关联
- 外部实体必须与至少一个流程相关联
- 不要让它变得太复杂;通常5 - 7个普通人可以管理流程
- DFD是不确定的——编号不一定表示顺序，它在与用户讨论时用于标识流程
- 数据存储不应该连接到外部实体，否则，这将意味着您将让外部实体直接访问您的数据文件
- 如果没有经过一个流程，数据流不应该存在于两个外部实体之间
- 有输入但无输出的过程被认为是黑洞过程
注意事项
不要混淆数据流和进程流
有些设计人员可能在看到从数据存储连接到流程的连接器时感到不舒服，因为没有看到数据请求的步骤以某种方式显示在图中。其中一些将试图通过在流程和数据存储之间添加连接器来表示请求，并将其标记为“请求”或“请求某些东西”，这是错误的。
请记住，数据流图是为表示信息交换而设计的。数据流图中的连接器用于表示数据，而不是表示流程流、步骤或其他任何东西。当我们将结束于数据存储的数据流标记为“请求”时，这意味着我们将请求作为数据传递到数据存储中。虽然这可能是在实现级别的DBMS做支持的使用功能,而摄入一些值作为参数并返回一个结果,在数据流图中,我们倾向于把数据存储作为唯一的数据夹,并不拥有任何处理能力。如果您想对系统流或流程流建模，那么可以使用UML活动图或BPMN业务流程图。如果希望对数据存储的内部结构建模，请使用实体关系图。
资源
- Food-Ordering-System.vpp
本教程的读者也可以阅读
- 什么是数据流程图(DFD)?如何绘制DFD?
- 如何编写有效的用例?
- 如何使用ERD对关系数据库设计建模?
- 如何开发现有的和将来的业务流程?
- 数据流程图与实例-客户服务系统
