第2章可行性研究.ppt

2.4 数据流图 以简单例子说明怎样画数据流图 假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。 2.4.2 例子 2.4 数据流图 首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部每天需要一张订货报表”，“通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。 第一步可以从问题描述中提取数据流图的4种成分： 2.4 数据流图 因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量，然而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。 第二步：再一次阅读问题描述，“采购部需要报表” 2.4 数据流图 系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配——每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储。 第三步：考虑数据流和数据存储 步骤一：从问题描述中提取数据流图的四种成分： （1）数据的源点/终点 采购员是数据终点，仓库管理员是数据源点。 （2）处理 ①采购部需要报表→说明没有报表→要有一个“产生报表”的处 ②零件库或出库（事务）→改变零件库存量→要有“事务加工”处理。 （3）数据流 ①要求系统把定货报表送给采购部→“定货报表”是一个数据流。 ②事务要从仓库送到系统中→“事务”是另一个数据流。 （4）数据存储 ①当有五个事务发生时立即要处理，但每天只产生一次定货报表→说明“事务加工”与“产生报表”这两个处理在时间上的不匹配→因此，“产生定货报表的数据”是一个数据存储。 ②零件库存量与库存量临界值均需保存→“库存清单数据”是一个数据存储。 成分 元素内容 源点/终点 1．采购员（终点） 2．仓库保管员（源点） 处理 1．产生报表 2．事务加工（处理事务） 数据流 1．定货报表 2．事务 数据存储 1．产生定货报表的数据信息 2．库存清单数据与库存临界值 组成数据流图的元素表 把数据流图的4种成分都分离出来以后（上图所示），就可以着手画数据流图了 步骤二： 步骤三： 把基本系统模型细化，描绘系统的主要功能 步骤四： 对功能级数据流图中描绘的系统主要功能进一步细化 X 1 3 2 1.1 1.2 1.4 1.3 2.1 2.2 1.1.1 1.1.2 2.1.3 2.1.2 2.1.1 2.2.2 2.2.3 2.2.1 顶层 中 间 层 底 层 先全局后局部,先整体后细节,先抽象后具体。 0图 1图 2图 1.1图 2.1图 2.2图 分层DFD 图 画数据流图的步骤 画顶层的数据流图 列出系统的全部数据源点和终点，将系统加工处理过程作为一个整体，即可得到顶层数据流图。 顶层图描述了系统的输入与输出。 画各层的数据流图 对系统处理过程进行逐步分解和细化，针对每层画出数据流图 画系统的内部 将系统的输入和输出数据流用一连串加工连接起来 画出总的数据流图 将最终数据流图画出，注意不要太复杂，要根据实际情况进行布局。 2.4 数据流图 2.4.3 命名 2.4 数据流图 数据流命名时应注意的问题 名字应代表整个数据流的内容，而不是仅仅反映它的某些成分 不要使用空洞的、缺乏具体含义的名字 在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解 2.4 数据流图 为处理命名时应注意的问题 通常先为数据流命名，然后再为与之相关联的处理命名。 名字应该反映整个处理的功能，而不是它的一部分功能。 名字最好由一个具体的及物动词加上一个具体的宾语组成。 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。 参考的原则： 数据守恒 即每个加工至少应有一个输入数据流和一个输出数据流 数据流图中各构成元素的名称必须具有明确的含义