软件工程之数据流图

 数据流图  

数据流图（ Data Flow Diagram ， DFD ）以图形的方式描绘数据在系统中流动和处理的过程，它只反映系统必须完成的逻辑功能，所以是一种功能模型。

数据流图强调的是数据流和处理过程，只关心系统做什么，而不关心系统怎么做；一般不考虑时序问题，即不表示过程的序列；只有数据流，没有控制流；既不反映判断和控制条件，也不反映循环过程。

1. 数据流图的基本成分

数据流图具有四种基本符号，即外部实体、数据流、数据处理过程和数据存储。数据流图所用的符号形状有多种，可以选择使用。表 4-5 给出了常用的符号表示。

表 4-5数据流图的常用符号

符号名称

符号形状

外部实体

（ External Entity ）

数据流

（ Data Flow ）

处理过程

（ Process ）

数据存储

（ Data Store ）

（ 1 ）外部实体（ External Entity ）。是指在所研究的系统外独立于系统而存在的，但又和系统有联系的实体，可以是某个人员、企业、某一信息系统或某种事物，是系统的数据来源或数据终点。确定系统的外部实体，实际上就是明确系统与外部环境之间的界限，从而确定系统的范围。

（ 2 ）数据流（ Data Flow ）。就是一束按特定的方向从源点流到终点的数据，它指出了数据及其流动方向。数据流可以由某一外部实体产生，也可以由处理过程或数据存储产生。对每一条数据流都要给予简单的描述，以便使用户和系统设计人员能够理解它的含义。

（ 3 ）处理过程（ Process ）。是对数据进行变换操作，即把流向它的数据进行一定的变换处理，产生出新的数据。处理过程的名称应适当反映该处理的含义，使之容易理解。每个处理过程的编号说明该处理过程在层次分解中的位置。

处理过程对数据的操作主要有：变换数据的结构，如将数据的格式重新排列；在原有数据内容基础上产生新的数据内容，如对数据进行累计或计算平均值。

（ 4 ）数据存储（ Data Store ）。数据流仅表达数据的流动方向，数据的保存则由数据存储来表达。数据存储指出了数据存储的逻辑描述。为避免数据流线条的交叉，如果在一张图中出现同样的数据存储，可在重复出现数据存储符号时再加一条竖线或左上角画一条斜线。为区别于其他数据存储，除了名称外，数据存储有一个标识（编号），一般用英文字母 D 和数字组成。

2. 数据流图的绘制

最初的数据流图应该真实地描绘用户当前的数据处理情况，系统分析员要将他在用户中所看到的、听到的事实如实画出来。用户目前正在使用的参数、图形、表格等资料就是“数据流”或“数据存储”，用户目前正在做的工作，如设计、图件的绘制等就是“处理”，其名称采用用户习惯上使用的名字。在刚开始时只要将实际情况真实地反映出来，而不要急于考虑系统如何实现。

由于习惯的原因，不同的分析员往往采取不同的画法，但是一般都遵循相同的原则，即同层次由外向里、不同层次自顶向下。

在绘制 DFD 时，首先画出系统的输入数据流和输出数据流，也就是先决定系统的范围，然后再考虑系统的内部。同样，对每个处理来说，也是先画出它们的输入输出数据流，再考虑该处理的内部，其基本步骤简述如下：

（ 1 ）画系统的输入和输出。这一步实际上是决定研究的内容和系统的范围，向用户了解“系统从外界接受什么信息和数据”，“系统向外界送出什么数据”，画在数据流图的外围。最开始并不十分清楚系统包括哪些功能，所以可以将系统的范围画得大些，即把可能的输入、输出都画进去。然后仔细分析，删除多余的部分，增添遗漏的部分。

（ 2 ）画数据流图的内部。一开始不考虑事物应当如何出现，只反映实际情况。首先找出数据流。如果有一组数据一起到达并一起处理，则应将这些数据画成一个数据流；反之，对不相关的数据，则应分成不同的数据流。找出数据流后，设法将它们与边界上的系统的输入、输出数据流连接起来，在需要对数据进行处理的地方画上处理过程。始终保持由输入到输出的方向，或者反过来，一旦在这个方向上遇到困难，就反过来处理。从开始的只代表整个系统从输入到输出的数据流中少量的处理过程开始构造 DFD 。接下来，再想像一下每个处理过程中是否存在内部的数据流，是否需要用 2 到 3 个处理过程及数据流来替换它。每个数据流应检查它的组成，来自何处，能否从输入项得到输出项。如果有数据存储，应画出相应的图示，并了解其组成及输入输出，从而可以对每一个处理过程进行改进，描述其处理过程中的细节。为了清晰可见，如果同一个数据存储多次出现，可以把它在图中多处画出来。最后，反复修改边界，消除多余，补上遗漏。

（ 3 ）为每一个数据流命名。数据流的命名与数据流图的可理解性密切相关。命名时应避免使用空洞的名字，例如“数据”、“信息”、“输出”等等，因为这些名字并没有反映出任何实质性的内容。如果发现难以命名，不妨考虑重新分解数据流或处理过程，很可能原来的组成不合适。名字要反映整个数据流的含义，而不是其中某一部分。

（ 4 ）为处理过程命名。先命名数据流，再命名处理过程，这样的次序反映了自上而下方法的特性。例如图 4-6 （ a ）中，当数据流已经命名后，处理过程 P 的命名可以自然地给予“检查成绩单的合格性”；而图 4-6 （ b ）中处理过程已命名，但无法为几个数据流命名。

图 4-6 处理过程的命名

为处理过程命名时，名字要反映整个处理过程，而不是它的一部分；名字应当是一种“动词 + 宾语”的形式；遇到不能适当命名的处理过程，要考虑重新分解。名字中只需用一个动词，如果必须用两个以上的动词，则应该将它分成几个处理过程。

人的思考过程是一种迭代的过程，不可能一次成功，需要完善，直到满意为止。因此要随时准备放弃原有的 DFD ，用改进的 DFD 来替代，通常画 DFD 需要多次的反复。

3. 数据流图的层次

数据流图的建立过程必须遵循自顶向下、逐层分解的原则，这是控制系统复杂性的方法，也是细化分析的基础。逐层分解的方式不是一下子引入太多的细节，而是有控制地逐步增加细节，实现从抽象到具体的过渡，因而将有利于对问题的理解。

用自顶向下、逐层分解的原则来画数据流图，就得到了一套分层的数据流图，分层的数据流图总是由顶层、中间层和底层组成的。

顶层数据流图描述了整个系统的作用范围，对系统的总体功能、输入和输出进行了抽象，反映了系统和环境的关系。为了画出顶层数据流图，必须首先识别不受系统控制的但影响系统运行的外部因素，从而确定出系统的外部实体和系统的数据输入源和输出对象。

通过对顶层图的了解、展开，将得到许多中间层的数据流图。中间层图描述了某个处理过程的分解，而它的组成部分又要进一步被分解。一个大型系统的中间层可能有七八层之多。中间层的展开应是化复杂为简单，但决不能失去原有的特性、功能和目标，而应始终保持系统的完整性和一致性。如果展开的数据流图已经基本表达了系统所有的逻辑功能和其必要的输入、输出，处理过程已经足够简单，不必再分解时，就得到了底层数据流图。底层图所描述的都是无需分解的基本处理过程。

建立分层的数据流图，应该注意编号、父图与子图的关系、局部数据存储以及分解的程度等问题。

（ 1 ）编号。适当地给出编号，有利于系统的理解。对处理过程的编号，随着逐层展开，也应反映出它的层次关系。每一张数据流图的编号即为上层图中相应处理过程的编号，每个处理过程的编号则是本图的图号加上点号和处理过程在本图的编号。例如第一层图中处理过程的编号为 1 ， 2 ，…；第二层图的编号应是 1.1 ， 1.2 ，…， 2.1 ， 2.2 ，…；依此方法，逐层给处理过程加上层次的序列号。

（ 2 ）父图与子图的关系。对任一层数据流图来说，称其上层图为其父图，其下层图为其子图。父图中某个处理的输入输出数据流应该与相应子图的输入输出数据流相同，层次数据流图的这种特点称为“平衡”。平衡是指子图的所有输入数据流必须是父图中相应处理的输入，子图的所有输出数据流必须是父图中相应处理的输出。

例如，图 4-7 中的处理 3 被分解成子图中的三个子处理，所有子图中的输入和输出数据流与父图中处理 3 的输入输出完全一致。

图 4-7局部数据存储

（ 3 ）局部数据存储。从图 4-7 可以发现，数据存储“成绩表”并没有在父图中出现。这是因为“成绩表”是完全局部于处理 3 的，它并不是父图中各处理之间的界面。根据“抽象”原则，在画父图时，只需画出父图中各个处理之间的联系，而不必画出各个处理内部的细节，所以“成绩表”不必画出。同理，数据流 L 、 M 、 N 等也不必画出。

画出一个数据存储可参考如下原则：当数据存储被用做 DFD 中某个处理之间的界面时，该数据存储就必须画出来，一旦数据存储作为 DFD 中的一个独立成分画出来时，它与其他成分之间的联系也应同时表达出来，即应画出每个处理是读还是写该数据存储。在图 4-7 中，当处理 3 被分解成 3.1 、 3.2 和 3.3 三个子处理时，“成绩表”是处理 3.1 和 3.3 的界面，应该画出来。

（ 4 ） 分解的程度。使用层次 DFD 就是不在一张图中把一个处理分解成它所有的基本处理。在一张图中画出过多的处理将使人难以理解，但如果每次只是将一个处理分解成 2 到 3 个处理，又可能需要过多的层次，也会带来一些麻烦。

经验表明，人们能有效地同时处理 7 个或 7 个以下的问题。一般是一次“最多不要超过 7 个”。当然，并不能机械地套用这个经验，而应该根据实际情况来定，关键是要使 DFD 易于理解。一般应做到分解自然，概念合理、清晰，在不影响易理解性的基础上适当地多分解，以减少层次 DFD 的层数。一般来说，因为上层是一些综合性描述，分解要快些，而在下层易理解性相对重要则分解慢些。

4. 数据流图的检查

数据流图是否正确，可以从数据流的输入和输出、父图与子图的平衡两方面来检查。

（ 1 ）数据流的输入和输出。一个处理所产生的某个输出数据在处理变换中既没有被产生，也没有作为输入数据输入到该处理，则该数据一定是在输入过程中被遗漏了。例如，图 4-8 中“决定比赛名单”这个处理是根据输入“学生名单”和“考试科目”来产生“获奖名单”的，如果“学生名单”和“获奖名单”的组成分别如下：

学生名单 = 专业 + 姓名 + 考试科目

获奖名单 = 考试科目 + 姓名 + 获奖等级

可以发现，“决定比赛名单”这个处理需要输出“获奖等级”数据，但这个处理本身并不产生“获奖等级”，而输入数据中也不包含它。可以肯定，该数据一定是在输入中被遗漏了。

图 4-8 数据流的检查

一个处理的某个输入既没有在处理中参加变换，也没有被输出，这可能不是错误。如果确有必要，就保留，否则去掉该数据。

（ 2 ）父图与子图的平衡。在层次 DFD 中，父图与子图不平衡的现象极易发生。当子图进行修改时，一定要及时对父图进行相应的修改，以保持平衡。

父图与子图是否平衡，不能仅从形式上看，要考虑其真正的内容。如果父图中有一个输入，而子图中有多个输入，此时看起来似乎不平衡，但是假如父图中的这一输入的成分与子图中多个输入组成的成分相同，也认为是平衡的。在图 4-9 中，订货单 = 审批报告 + 待批订货单 + 付款单。

图 4-9 平衡原则

DFD 是直接与用户交流的工具，也是系统开发的基础。对于一个大型系统的理解不可能一开始就是十全十美的，要经过逐步去粗取精、去伪存真的过程。因此，在开始分析一个系统时，尽管对问题的理解并不确切，但还是可以把所理解的 DFD 画出来，然后逐步修改，以获得较高的正确性和易理解性。

5. 数据流图的改进

DFD 的改进可从简化处理间的联系、注意分解的均匀以及适当地命名等三个方面着手。

（ 1 ）简化处理间的联系。其基本手段是“分解”，用以控制复杂性。分解不能随心所欲地进行，否则可能反而使问题复杂化。合理的分解是将一个问题分解成相对独立的几个部分，每一部分可以单独理解，一个复杂的问题就被几个比较简单的问题取代。 DFD 中，处理间的数据流越少，各处理之间越相对独立。因此，应尽量减少处理间输入输出数据流的数目。

（ 2 ）注意分解的均匀。理想的分解是尽可能将一个问题分解成大小均匀的几个部分。如果在一张图中，某些处理已经是基本处理，而另一些处理还可进行多层分解，则这张图是难以理解的，因为图中某些部分描述的是细节，而另一部分描述的还是较高层的抽象，此时应考虑重新分解。

（ 3 ）适当地命名。 DFD 中各成分的名称是与其易理解性直接相关的，应该注意名称的选取。数据流和数据存储的命名，应尽量避免产生错觉，以减少系统设计、系统实施等阶段的错误。如果难以为某个成分取名，往往是分解不当的迹象，可考虑重新分解。

6. 数据流图示例

下面以高等院校学生学籍管理系统为例说明数据流图的画法。学籍管理系统要记录学生从入学到毕业整个在校期间的情况，学生毕业时把学生的情况提供给用人单位。

（ 1 ）初步确定基本元素。首先确定数据的源点和终点。根据系统的描述，确定数据的源点和终点分别为“招生部门”和“用人单位”。然后考虑数据流。“招生部门”为系统提供“新生名单”，经系统处理，提交“毕业生登记表”给“用人单位”。得到如图 4-10 所示的顶层图。

图 4-10 学籍管理系统的顶层数据流图

（ 2 ）分解。接下来对顶层图进行细化，从而描述出系统的主要功能。学籍管理中包含学生学习成绩管理、学生奖惩管理、学生变动管理、毕业生管理等部分。由此，将图 4-10 展开成图 4-11 。图 4-10 中的数据流都必须反映在图 4-11 中。“学籍表”记载了学生的基本情况，如学籍变动情况、各学期课程的学习成绩、在校期间的奖惩记录等。

图 4-11学籍管理系统的第一层数据流图

可对图 4-11 进一步分解。例如，分析“成绩管理”，进入此处理的数据流有“学期成绩单”与“补考成绩单”，因此可分解为“分析学期成绩”与“分析补考成绩”两个处理，并且还要进行学期成绩登记与补考成绩登记。根据对学期成绩的分析，得出留退名单、获奖名单以及成绩统计表。这样， P2 框“成绩管理”扩展为图 4-12 。

图 4-12 “成绩管理”的展开

对图 4-12 中的一些处理，还可以进一步展开。如分析学期成绩，要登记“成绩一览表”，根据“成绩一览表”评出成绩优秀奖，决定留级、退学建议名单，给学生发送成绩单等。这样，图 4-12 中“分析学期成绩（ P2.1 ）”展开为图 4-13 。