7.DFD特性
抽象性:在DFD中具体的组织机构、工作场所、物质流等都已经去掉,只剩下信息和数据存储、流动、使用以及加工的情况。故描述的是抽象出来的数据。
概括性:它把系统对各种业务的处理过程联系起来考虑,形成一个总体,可反映出数据流之间的概括情况。
8.DFD用途
自顶而下分析系统的信息流程。
在图上确定需要计算机处理的部分。
向数据库设计过渡。
根据数据流向确定存取方式。
能够对应一个处理过程。
9.DFD优缺点
总体概念强:每层明确“ 干什么”、“ 需要什么”、“给出什么”。
可反映出数据流向的处理过程。
容易及早发现系统各部分逻辑错误。
易与计算机处理对照。
不直观。
人工绘制太麻烦,工作量较大。
四、画分层数据流图时应注意的问题
下面从四个方面讨论画分层数据流图时应注意的问题。
1.合理编号
分层数据流图的顶层称为0层,称它是第1层的父图,而第1层既是0层图的子图,又是第2层图的父图,依此类推。由于父图中有的加工可能就是功能单元,不能再分解,因此父图拥有的子图数少于或等于父图中的加工个数。
为了便于管理,应按下列规则为数据流图中的加工编号:
l 子图中的编号为父图号和子加工的编号组成。
l 子图的父图号就是父图中相应加工的编号。
为简单起见,约定第1层图的父图号为0,编号只写加工编号1、2、3...,下面各层由父图号1、1.1等加上子加工的编号1、2、3...组成。按上述规则,图的编号即能反映出它所属的层次以及它的父图编号的信息,还能反映子加工的处理信息。例如1表示第1层图的1号加工处理,1.1、1.2、1.3...表示父图为1号加工的子加工,1.3.1、1.3.2、1.3.3...表示父图号为1.3加工的子加工。
为了方便,对数据流图中的每个加工,可以只标出局部号,但在加工说明中,必须使用完整的编号。例如图5-4-5可表示第1层图的1号加工的子图,编号可以简化成图中的形式。

图5-4-5 简化子图编号示例
2.注意子图与父图的平衡
子图与父图的数据流必须平衡,这是分层数据流的重要性质。这里的平衡指的是子图的输入、输出数据流必须与父图中对应加工的输入、输出数据流相同。但下列两种情况是允许的,一是子图的输入/输出流比父图中相应加工的输入/输出流表达得更细。例如,在图5-4-6中,若父图的“订货单”数据流是由客户、品种、帐号、数量四部分组成,则图中的子图和父图是平衡的。在实际中,检查该类情况的平衡,需借助于数据词典进行。二是考虑平衡时,可以忽略枝节性的数据流。例如图5-4-6,在4号加工的子图中4.3号子加工中增加了一个输出,表示出错的数据流(由虚线所示),则子图和父图仍可看作是平衡的。

图5-4-6 子图和父图的平衡图片
3.局部文件
图5-4-7中的父图和子图是平衡的,但子图中的文件W并没在父图中出现。这是由于对文件W的读、写完全局限在加工3.3之内,在父图中各个加工之间的界面上不出现,该文件是子图的局部文件或为临时文件。
图5-4-7 数据流图中的局部文件
应当指出的是,如果一个临时文件在某层数据流图中的某些加工之间出现,则在该层数据流图中就必须画出这个文件。一旦文件被单独画出,那么也需画出这个文件同其它成分之间的联系。
4.分解的程度
对于规模较大的系统的分层数据流图,如果一下子把加工直接分解成基本加工单元,一张图上画出过多的加工将使人难以理解,也增加了分解的复杂度。然而,如果每次分解产生的子加工太少,会使分解层次过多而增加作图的工作量,阅读也不方便。经验表明,一般说来一个加工每次分解量最多不要超过七个为宜。同时,分解时应遵循以下原则:
l 分解应自然,概念上要合理、清晰。
l 上层可分解的快些(即分解成的子加工个数多些),这是因为上层是综合性描述,对可读性的影响小。而下层应分解得慢些。
l 在不影响可读性的前提下,应适当地多分解成几部分,以减少分解层数。
l 一般说来,当加工可用一页纸明确地表述时,或加工只有单一输入/输出数据流时(出错处理不包括在内),就应停止对该加工的分解。另外,对数据流图中不再作分解的加工(即功能单元),必须作出详细的加工说明,并且每个加工说明的编号必须与功能单元的编号一致。
五、数据流图的修改
前面介绍了画数据流图的基本方法。对于一个大型系统来说,由于在系统分析初期人们对于问题理解的深度不够,在数据流图上也不可避免地会存在某些缺陷或错误。因此还需要进行修改,才能得到完善的数据流图。这里介绍如何从正确性和可读性方面对数据流图进行改进。
1.正确性
数据流图的正确性,可以从以下几个方面来检查:
(1)数据守恒
(2)文件使用
在数据流图中,文件与加工之间数据流的方向应按规定认真标注,这样也有利于对文件使用正确性的检查。例如,在图5-4-8中,因为文件1和文件2是子图的局部文件,所以在子图中应画出对文件的全部引用。但子图中文件2好象一个“渗井”,数据只流进不流出,显然是一个错误。

图5-4-8 局部文件使用错误
(3) 子、父图平衡
造成子图与父图不平衡的一个常见原因是在增加或删除一个加工时,忽视了对相应父图或子图的修改。在检查数据流图时应注意这一点。
(4) 加工与数据流的命名
加工和数据流的名字必须体现被命名对象的全部内容而不是一部分。对于加工的名字,应检查它的含义与被加工的输入/输出数据流是否匹配。
一个加工的输出数据流仅由它的输入数据流确定,这个规则绝不能违背。数据不守恒的错误有两种,一是漏掉某些输入数据流,二是某些输入数据流在加工内部没有被使用。虽然有时后者并不一定是个错误,但也要认真考虑,对于确实无用的数据就应该删去,以简化加工之间的联系。
在检查数据流图时,应注意消除控制流。
2.可读性
数据流图的可读性,可以从以下几个方面来提高:
(1)简化加工之间的联系
各加工之间的数据流越少,各加工的独立性就越高。因此应当尽量减少加工之间数据流的数目,有必要时可采用后面要介绍的步骤对数据流图重新分解。
(2)分解应当均匀
在同一张数据流图上,应避免出现某些加工已是功能单元,而另一些加工却还应继续分解好几层的情况出现。否则应考虑重新分解。
(3)命名应当恰当
理想的加工名由一个具体的动词和一个具体的宾语(名词)组成。数据流和文件的名字也应具体、明确。
3. 数据流图重新分解的步骤
有时需要对作出的部分或全部数据流图作重新分解,可按以下步骤进行:
(1)把需要重新分解的所有子图连成一张;
(2)根据各部分之间联系最少的原则,把图划分成几部分;
(3)重建父图,即把第二步所得的每一部分画成一个圆圈,各部分之间的联系就是加工之间的界面;
(4)重建各张子图,只需把第二步所得的图,按各自的边界剪开即可;
(5)为所有加工重新命名、编号。
例如,图5-4-9中加工2和其它加工的联系太复杂以致很难独立理解,所以其结构不太合理。因为图5-4-9的子图是由不相连的两部分组成的,所以将它们的父图加工分成两个更为合适。

图5-4-9 结构不合理的数据流图
六、数据流图的示例
百货商店业务管理系统顶层数据流程图;
百货商店业务管理系统数据流程图一级分解;
销售处理二级数据流程;
采购处理二级数据流程;
会计处理二级数据流程;
七、数据字典(Data Dictionary,DD)
在数据流图的基础上,还需对其中的每个数据流、文件和数据项加以定义, 我们把这些定义所组成的集合称为数据字典(Data Dictionary)。数据流图是系统的大框架,而数据字典以及下面将要介绍的加工说明则是对数据流图中每个成分的精确描述。它们有着密切的联系,必须结合使用。
我们把上述每一个定义作为数据字典中的一个条目。因此,在数据字典中有三种类型的条目:数据流条目、文件条目和数据项条目。下面分别讨论。
1.数据流条目
数据流条目对每个数据流进行定义,它通常由四部分组成:数据流名、别名、组成和注释。其中,别名是前面已定义的数据流的同义词;组成栏是定义的主要部分,通常是列出该数据流的各组成数据项;注释栏用于记录其它有关信息,例如该数据流在单位时间中传输的次数等。
如果数据流的组成很复杂,则可采用“自顶向下,逐步分解”的方式来表示。例如,“课程”数据流可写成:
课程=课程名+教师+教材+课程表
课程表={ 星期几+第几节+教室 }
只要依次查这两个条目,就可确切了解“课程”的含义。
在数据字典各条目的定义中,常使用下述符号:
= 表示“等价”;
+ 表示“与”;
[ | ] 表示“或”,即选括号中某一项,括号中各选择项用“|”隔开。例如,三好学生=[ 甲|乙|丙|丁 ];
( ) 表示“可选”,即从括号从中任选一项,也可一项都不选;
{ } 表示“重复”,即重复括号内的项,重复次数的上、下界标在括号右边。例如{X}51 表示把X加工重复1-5次。若在重复括号上没有附加重复次数的上下界时,则表示0次或多次重复。
数据流条目的编写格式见表5-4-1、5-4-2“职工基本情况”和“查询条件”数据流条目。
表5-4-1
数据流名:职工基本情况 别 名:无 组 成:职工号+姓名+性别+出生时间+参加工作时间+职称+工作部门+工资+婚否 注 释: |
表5-4-2
数据流名:查询条件 别 名:无 组 成:[查工资情况|查工作部门|查职称|查职工号] 注 释:数据量:约70次/天; 今后还要增加查询种类 |
2.文件条目
文件条目用来对文件(或数据库)进行定义。它由五部分组成:文件名、编号、组成、结构和注释。其中组成栏的定义方法与前面的数据流条目相同。结构栏用于说明重复部分的相互关系,比如指出是顺序或索引存取。文件条目的格式见表5-4-3 “人事档案文件”的条目。
表5-4-3 人 事 档 案 文 件
文件名:人事档案文件 编 号:EMP 组 成:职工号+姓名+出生时间+参加工作时间+职称+工作部门+工资+婚否 结 构:以职工号为关键字、索引存取 注 释:今后还将增加数据项 |
3.数据项条目
数据项条目用来给出数据项的定义。由于数据项是数据的最小单位,是不可分割的,因此数据项条目只包含名称、代码、类型、长度和值的含义内容等。对于那些足以从名称看出其含义的“自说明”型的数据项,则不必在条目中再解释其含义。数据项条目的格式见表5-4-4所示的“人事管理系统的数据项条目”。
表5-4-4 人事管理系统数据项条目
数据项名 | 代码 | 类型 | 长度 | 小数位 | 含义 | 别名 | 注释 |
职工号 | ZGH | 数值型 | 6 |
|
|
|
|
姓名 | XM | 字符型 | 8 |
|
|
|
|
性别 | XB | 字符型 | 2 |
|
|
|
|
出生时间 | CSSJ | 日期型 | 8 |
|
|
|
|
参加工作时间 | CZSJ | 日期型 | 8 |
|
|
|
|
婚否 | HF | 逻辑型 | 1 |
|
|
|
|
职称 | ZC | 字符型 | 8 |
|
|
|
|
工作部门 | BM | 字符型 | 10 |
|
|
|
|
工资 | GZ | 数值型 | 6 | 2 |