软件工程 第4版 教学课件 作者 张海藩 吕云翔 编著 03第三章：例一.docx

《软件工程 第4版 教学课件 作者 张海藩 吕云翔 编著 03第三章：例一.docx》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、3.5.2例子下面通过一个简单例子具体说明怎样画数据流图。假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据：零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。数据流图有4种成分：源点或终点、处理、数据存储和数据流。画出上述定货系统的数据流图可采用以下步骤。①从问题描述中提取数据流图的4种成分。首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部

2、每天需要一张定货报表”，“通过放在仓库中的终端把事务报告报告给定货系统”，所以采购员是数据终点，而仓库管理员是数据源点。②接下来考虑处理。再一次阅读问题描述，“采购部需要报表”，显然他们还没有这种报表，因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量，而任何改变数据的操作都是处理，因此，对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。③最后考虑数据流和数据存储：系统把定货报表送给采购部，因此定货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时

3、间上明显不匹配—每当有一个事务发生时立即处理它，然而每天只产生一次定货报表，因此，用来产生定货报表的数据必须存放一段时间，也就是应该有一个数据存储。注意，并不是所有数据存储和数据流都能直接从问题描述中提取出来。例如，“当某种零件的库存数量少于库存量临界值时就应该再次定货”，这个事实意味着必须在某个地方有零件库存量和库存量临界值这样的数据。因为这些数据元素的存在时间看来应该比单个事务的存在时间长，所以认为有一个数据存储保存库存清单数据是合理的。表3.1列出了上面分析的结果，其中加星号标记的是在问题描述中隐含的成分。表3.1组成数据流图的元素可以从描述问题的信息中提取源点/

4、终点处理数据流数据存储采购员仓库管理员产生报表处理事务定货报表零件编号零件名称定货数量目前价格主要供应者次要供应者事务零件编号*事务类型数量*定货信息（见定货报表）库存清单*零件编号*库存量库存量临界值一旦把数据流图的4种成分分离出来后，就可以着手画数据流图了。但是要注意，数据流图是系统的逻辑模型，而任何计算机系统实质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。因此，任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。对于上述的定货系统可以画出如图3.4所示的基本系统模型。图3.4定货系

5、统的基本系统模型（突出表明了数据的源点和终点）从基本系统模型这样非常高的抽象层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点/终点是一目了然的，因此它是很有价值的沟通工具。然而，图3.4所示的基本系统模型毕竟太抽象了，从这张图上对定货系统所能了解到的信息非常有限。下一步应该把基本系统模型细化，描绘系统的主要功能。从表3.1可知，“产生报表”和“处理事务”是系统必须完成的两个主要功能，它们将代替图3.4中的“定货系统”（见图3.5）。此外，细化后的数据流图中还增加了两个数据存储：处理事务需要“库存清单”数据；产生报表和处理事务在不同时间

6、，因此需要存储“定货信息”。除了表3.1中列出的两个数据流之外还有另外两个数据流，它们与数据存储相同。这是因为从一个数据存储中取出来的或放进去的数据通常和原来存储的数据相同，也就是说，数据存储和数据流只不过是同样数据的两种不同形式。在图3.5中给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。考虑通过系统的逻辑数据流，当发生一个事务时必须首先接收它；随后按照事务的内容修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次定货，也就是需要处理定货信息。因此，把“处理事务”这个功能分解为下述3个步

7、骤：“接收事务”、“更新库存清单”和“处理定货”（见图3.6），这在逻辑上是合理的。图3.5定货系统的功能级数据流图图3.6把处理事务的功能进一步分解后的数据流图我们为什么不进一步分解“产生报表”这个功能呢？因为定货报表中需要的数据在存储的定货信息中全都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。同样道理，对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。总之，当进一步分解将涉及如何具体地实现一个功能时，就不应该再分解了。在对数据流图分层细化时必须保持