1．我们需研制一个“教育基金会的捐助资金管理系统”的例子来说明数据流图的具体建模方法。要求如下：
⑴由捐助者向基金会提出捐助请求，经身份确认后被接受，对捐助人进行登记并授予捐助证书，捐款存入银行。
⑵由教育单位提出用款申请，在进行相应的合法性校验和核对相应的捐款储备后做出支出。
⑶每月给基金会的理事会一份财政状况报表，列出本月的收入和支出情况和资金余额。
为了搞清系统中的各种关系，用数据流图的方法进行分析和建模。
初步确定基本元素画数据流图的第一步是确定图中数据的源点或终点以及数据流。首先考虑数据的源点或终点。从以上对关系的描述可知：“捐助者向基金会提出捐助请求”，“由教育单位提出用款申请”，“每月给基金会的理事会一份财政状况报表”，所以“捐助者”和“教育单位”是数据的源点，而“理事会”是数据的终点。然后考虑数据流。由于系统需要把每月的财政报表提供给理事会，因此财政报表是一个数据流；同样，捐助者的捐款请求和教育单位的用款申请都是系统的数据流。在问题的描述中，“给理事会财政状况报表”表明“财政报表”也是数据流。这样我们得到如图1所示的顶层图。顶层图由若干个数据的源点和终点和一个加工组成。这个加工就代表了整个系统的功能。
2. 分解
接下来是对顶层数据流图进行细化，从而描述系统的主要功能。可以采用从外向里的方法进行。由上面的讨论可知，数据流“捐款请求”是作为基金会的收入来处理的，可以加上一个“收入处理”的加工；数据流“用款请求”是作为基金支出来处理的，应加上一个“支出处理”加工；数据流“财政报表”应由加工“产生报表”来完成。这三个加工将代替图1中的“资金管理系统”。此外，数据流增加了一个数据存储，因为“处理收入”、“处理支出”和“产生报表”都需要从“财政状况”数据库中取得数据。与这个数据存储相对应的三个数据流，分别用于三个不同的加工访问数据存储中的数据。可以注意到这三个数据流与数据存储的命名相同，因为从一个数据存储中取得的数据通常和它本来存放的数据形式一样。这说明，数据存储和数据流只是同样的数据处于不同状态的两种形式。
经过这一步的数据流如图2所示，其中给数据存储和加工都加上了编号。
为了进行进一步的分解，检查系统中的收支处理的加工。当发生一个收入，或者支出的请求时，系统必须具有接受、审查和登记（或批准）的功能，因此可以分解出一个“接受请求”的加工。在请求接受后，需要检查请求的合法性，因此需要分解出一个检查请求合法性的加工。检查的依据是相应的有关捐助者或教育单位的信息，因此就有相应的数据存储。对于通过了合法性检查的请求，需要分解出一个处理用于更新收支状况数据库的数据。由此可见，需要把“收入处理”或“支出处理”分解成为三个处理步骤，即“接受请求”、“收入（/支出）合法性检查”和“登记（/批准）收入（/支出）”三个加工。此时应考虑增加必要的数据存储作为子加工间的信息接口。各种不同的考虑的数据流图，我们在对这一问题进行课堂教学的讨论时就产生了许多的方案。读者也可以提出自己不同的想法及与图3不同的方案。
注意，在此我们没有必要对“产生报表”这个加工进行继续分解。就是因为，提供的财政报表中的所有信息在数据存储“收支状况”中都已经存在，而“产生报表”这个加工只不过是按照一定的格式排列和输出这些信息。继续分解这个功能将涉及到系统的具体实现细节，是不应该在数据流图上出现的。所以，当一个功能的继续分解涉及到功能的具体实现时，在数据流图上就没有再分解这个功能的必要了。经过进一步细化的数据流图如图3所示。
第二大题
假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。
