假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述的数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。

数据流图有4种成分：

1、源点和终点

2、处理

3、数据存储

4、数据流

因此，第一步可以从问题描述中提取数据流图的4种成分：

①首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部每天需要一张订货报表”，“通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。

②接下来考虑处理，再次一次阅读问题描述，“采购部需要报表”，显然他们还没有这种报表，因此必须有一个产生报表的处理。事务的后果是改变零件库存量，然而任何改变数据的操作都是处理，因此对事物进行的加工是另一个处理。

③最后，考虑数据流和数据存储：系统把订单报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个在时间上明显不匹配———每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，用来产生订货报表的数据必须存放一段时间，也就是应该有应该数据存储

组成数据流图的元素可以从描述问题的信息中提取出来

源点/终点	处理
采购员 仓库管理员	产生报表 处理事务
数据流	数据存储
订货报表     零件编号     零件名称     订货数量     目前价格     主要供应者     次要供应者 事务     零件编号     事务类型     数量	订货信息 库存清单      零件编号      库存量      库存量临界值

一旦把数据流图的4种成分都分离出来以后，就可以画数据流图了，但是，怎样开始画呢？

注意：数据流图是系统的逻辑模型，然而任何计算机系统实质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。因此，任何系统的基本模型都是由若干数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。

 从基本系统模型这样非常高的层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据终点/源点一目了然，因此它是很有价值的通信工具。

然而，订货系统的基本系统模型图毕竟太抽象，从这张图对订货系统所能代表的信息非常有限。下一步应该把基本系统模型细化，描绘系统的主要功能。从信息表中可得，“产生报表”和“处理事务”是系统必须完成的两个主要功能，它们将代替订货系统的基本系统模型图中的订货系统，此外，细化后的数据流图还增加了两个数据存储：处理事务需要“库存清单“数据；产生报表和处理事务在不同时间进行，因此需要存储”订单信息“。除了订货系统的基本系统模型图中列出的两数据流之外，还有另外两个数据流，它们与数据存储相同。这是因为从应该数据存储中取出来的或放进去的数据通常和原来数据相同，也就是说，数据存储和数据流只不过是同样的数据的两种不同的形式。

订货系统的功能级数据流图

接下来应该对功能级数据图中描述的系统主要功能进一步细化。考虑通过系统的逻辑数据流：当发送一个事务时必须首先接收它；随后按照事务的内部修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次订货，也就是要处理订货信息。因此，把“处理事务”这个功能分解为下述3个步骤，这在逻辑上是合理的：“接受事务”,"更新库存清单","处理事务"。

为什么不进一步分解“产生报表”这个功能呢？订货报表中需要的数据在存储的订货信息中全部都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。同样道理。对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。总之，当进一步分解将涉及如何具体实现一个功能时就不应该再分解了。

当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同。

此外还要注意图中处理编号的方法。处理1.1，1.2和1.3是更高层次的数据流图中处理1的组成元素。如果处理2被进一步分解，它的组成元素的编号将是2.1，2.2，……；如果把处理1.1进一步分解，则将得到编号为1.1.1，1.1.2，……的处理。