软件工程DFD图示例

例1:绘制预订系统的DFD图。现有的预订系统接收客户发送的订单并验证订单。验证过程是根据图书目录检查订单的正确性，同时根据客户档案判断他们是新客户还是老客户，是否有信誉。已验证的正确订单被临时存储在订单文件中进行处理。订单的批量处理，根据出版社档案对出版社的订单进行分类汇总，保存订单存根，然后将汇总的订单发送给各出版社。绘制步骤是：首先，确定外部实体(客户、出版社)和输入输出数据流(订单、出版社订单)。然后分解顶层处理(验证顺序、汇总顺序)。确定使用的文件(5个文件，如图书目录文件和客户文件)。数据流用于连接所有部分以形成数据密封。应当注意，数据流图不是传统的流程图或框图，数据流也不是控制流。数据流图从数据的角度描述系统，而框图从处理数据的工人的角度描述系统。数据流图中的箭头是数据流，而框图中的箭头是控制流，表示程序执行的顺序。例2下图是培训中心管理系统的数据流程图：由于只有一层，分解的过程很难理解，如果其中一个过程比较复杂，例如3号处理“付款”和7号处理“审核”暂时还比较复杂和难以理解，如果分解一直持续到每个过程简单易懂，会影响需求分析结果的可读性。如图所示，如果系统规模较大，仅用一个DFD图很难描述，这将使系统变得复杂和难以理解。为了降低系统的复杂性，我们采用了“逐层分解”的技术，并绘制了分层的DFD图。绘制分层DFD图的一般原则是：“先全局后局部，先整体后细节，先抽象后具体。”通常，这个分层的DFD图分为顶层、中间层和底层。顶层图说明了系统的边界，即系统的输入和输出数据流，并且只有一个顶层图。底层图由一些不能分解的过程组成，这些过程足够简单，可以称为基本过程。顶层和底层之间是中间层。中间层的数据流图描述了某个流程的分解，其组件需要进一步分解。在绘制每一层的DFD图纸时，应该是“从外向内”。绘制分层DFD图的具体步骤：首先确定系统范围，在顶层绘制DFD图。逐层分解顶部的DFD图，得到几个中间的DFD图。画出底部的DFD图。绘制分层数据流图时，遇到的第一个问题是如何分解它。你不能一次将一个过程分解成所有的基本过程。如果你在一幅画中画了太多的过程，那是很难理解的。但是，如果您一次只将一个过程分解成两个或三个过程，您可能需要分解太多层次，这也将影响系统的可理解性。一个过程一次分解成多少个子过程是合适的？根据经验，“不超过7”。统计结果显示，人们可以同时有效地处理七个或更少的问题，但当问题超过七个时，治疗效果就会下降。当然，它不能机械地应用。关键是使数据流图易于理解。同时，有几个原则可供借鉴：分解要自然，概念要合理清晰。只要它不影响数据流图的“可理解性”，它就可以被适当地分解成几个部分，从而可以减少层次图的层次。一般来说，它在上层可以分解得更快，但在中、下层分解得更慢，因为上层是一个全面的描述，“可理解性”相对来说并不重要。绘制分层DFD图的基本原则所谓的数据保存是指处理的输入和输出数据流是否匹配，即每个数据流是否匹配加工分解的原则是自然的：概念合理清晰；一致性：理想的分解是将一个问题分解成几个大小一致的部分；分解度：一般来说，每个过程应该分解到7个子过程，并且应该分解到基本过程。子图与父图的平衡：父图中某个处理的输入输出数据流应该与对应子图的输入输出相同(对应)。层次数据流图的这一特性被称为子图和父图之间的“平衡”。显然，图2.13中的子图与父图是不平衡的。子图是父图中过程2的分解。过程2有输入数据流R和M以及输出数据流T，而子图只有一个输入数据流N，但是有两个输出数据流T和S.在图2.14中，子图是父图中过程4的分解。虽然流程4表面上只有一个输入数据流“订单”，但子图有三个输入数据流，如果订单由三个部分组成：“客户”、“帐号”和“数量”，则有以下数据条目：订单=客户帐号(2.2.5数据字典当某个文件用作某些流程之间的接口时，必须绘制该文件。一旦文件被绘制成数据流图中的一个独立组件，它和其他组件之间的关系也应该同时表达。理解一个问题总是经历一个从不正确到正确，从不准确到准确的过程。需求分析的过程总是重复的，一次成功的可能性很小，特别是对于复杂的系统。因此，系统分析师应该随时准备修改和改进数据流图，与用户达成共识，获得明确的需求，从而获得更加正确和清晰的需求描述，使设计和编程阶段顺利进行。这样做是必要的，也是值得的。层次DFD图的改进：的DFD图必须反复修改以获得最终目标系统的逻辑(目标系统的DFD图)。改进的原则与绘制分层DFD图的基本原则是一致的。DFD图的改进可以从以下几个方面考虑：检查数据流的正确性，数据保存子图和父图的平衡文件是否被合理使用。特别注意输入/输出文件的数据流。提高DFD图的可理解性，简化流程之间的关系(流程之间的数据流越少，独立性越强，可理解性越好)。提高分解的均匀性。正确的命名(每个组件的名称都是明确、准确和具体的)。