四、数据流图

在前面调查的基础上，我们需要对资料进行综合分析，其主要工具就是数据流图。数据流图只用四种记号：数据流、数据存储、数据处理及外部实体。图 15.4 所示的就是这四种记号。

箭头表示数据流。它是指各种各样的信息的传输，包括数据的传递、抽取、存入等等，在物理实现的手段方面，它可以包括报表的传递、电报、信件、电话的收发、计算中各种磁性介质材料的传送以及使用。总之，这个箭头表示的含义是十分广泛的。
数据存储的含义是十分广泛的，它可以指帐本、记录本，也可指计算机中存储的各种文件及数据库。
数据处理的含义包括任何一种对信息的加工，例如，排序、算术运算、逻辑判断、统计分析等。它既包括手工的加工处理。也包括使用计算机的加工处理。
外部实体是指在系统之外的、与系统有信息交流的部门或人员。它们的情况及属性可以是非常不同的，对于系统而言，它们是信息的来源或去向。

利用这些记号，依据前几节介绍的各种图表所记载的素材，我们可以着手绘制数据流图。

由于系统比较复杂又是多层的，不可能一次把所有问题描述清楚，我们采取自顶向下逐步分析的方法来绘制数据流图。

首先，我们把系统看作一个整体，或一个总的数据处理模块，只要指明它和各有关外部实体之间的信息交换关系就够了，暂时不去考虑它内部的各种信息存储、信息处理及数据流。这样，我们就得到了最粗略的，或者说最顶层的数据流图。根据这样的想法，我们实例中的系统中可用图表示出来。通过图 15·5 表明，这个系统与三种外部实体有数据交换关系，图中的五个箭头的含义为：a.合同及送货通知；b.合同及催货单；c.发料单据；d·领料申请；e.汇总及统计报表。

这样一个简单的数据流图当然不能反映系统的全部情况，然而，它是一个对系统的高度概括的描述，它揭示了这个系统的环境，它和环境的关系，它的总功能。这些是我们考虑一个系统时必须首先考虑的制约因素。

为了更详细地描述系统的状况，我们需要把图中的总功能模块进行分解。分解的第一步，是按工作的部门划分。在我们的例子中，分为由外协组和仓库。因此，我们可以把总的功能分成合同管理和库存管理两大模块。进行这样划分之后，我们可以看到，马上就有许多问题需要我们明确。这些问题包括：

·上一层图中和各外部实体间的数据交换应落实到哪一个模块上；

·这两个模块之间的数据流是怎样的；

·在这两个模块之间的数据传输中有些内容需要临时或永久序储。

如果我们在前一阶段已经积累了足够的素材，回答这些是不困难的。在我们的实例中，很容易看出，厂领导和车间并不直接和合同管理相联系，而是和库存管理打交道，而外协厂主要是和合同管理交换信息，只有送货通知是送交库存管理的。这样，第一张图中的五个数据流就分别落实到这两个模块上，b，c，d，e 的内容同前，a 的内容分为两部分，合同是送交合同管理部分，而送货通知则送交库存管理部分，前者用 a′表示，后者用 a″表示。

两部分之间的数据传输关系是这样的：外协组签订的合同需要供仓库使用，因为接收货物时要查对，当库存管理部分在发料时发现缺货时，就向合同管理部分发出要求催货的信息。这两者的处理情况是有区别的。合同从签订到到货是有一定时间间隔的，而且可能是一次订货分期付货。在这种情况下，用一个箭头是无法清晰地表达其中的复杂情况的。事实上，从信息处理的角度讲，这里需要补充一个中间的，与两个处理模块都有关系的数据存储部分，即合同的档案，或合同的登记册，而库存管理部分则在到货时从中查找有关的合同，并登记到货数量及日期等信息。催货申请则是同步的动作，库存管理部分提出订货申请后，合同管理部分填写催货单，发出催货单，因此并没有中间存储的问题。事实上催货申请只是一个电话，或库工的口头要求，并没有存储起来。这种情况下用一个箭头表示就够了。

这样，新增加的系统内部的数据流就包括了：f.新合同登记入册；g.根据送货通知查找合同；h.登记到货日期及数量；j.催货申请；j.根据催货申请查找合同。

图 15.6 就是以上分解的结果。从方法上讲，这里要注意两点。

数据流的意义必须明确，即每个箭头的出发端和终止端应有同样的解释。从内容上、含义上、查我方式上都应一致，否则就可能出现各种各样的问题。当然，这种情况的出现常常是由于遗漏了中间的数据处理模块或数据存储模块。上面的例子中如果从合同管理向库存管理直接画一个箭头，那就是遗漏了数据存储。
数据存储的添加，应限于各功能模块的接口处。各功能模块的内部，为了其自身处理工作的需要所设置的数据存储一般不急于添加进去。因为这里还是比较粗略的分析。而且，各功能模块内部的数据存储一般不影响全局，我们只要抓住这个模块的输入输出，就能使它与整个系统协调一致地工作。在分解的每一个层次上，我们都把注意力集中在该层次的各个模块之间的关系上，而把各个模块内部的情况，包括处理机制及信息存储，暂时置于不顾，即把它们看作“黑匣”。这对于我们有步骤地、有层次地认识一个复杂系统，是一种行之有效的方法。

下一步的分解是按业务区分。根据我们的调查，合同管理和库存管理都包括几项业务，合同管理包括签订合同及监督执行（即催货），库存管理包括进货、发料和月底结帐。我们可以把第二层数据流图中的两个功能模块进一步分解成五个与各项业务相对应的功能模块，这样就得到了图 15.7 的第三层数据流图。我们可以和上一层一样，对于每一个箭头和每一个功能模块进行详细的分析。例如，我们至少能发现，在月底结帐时，也有可能提出催货申请，那么，图 15.6 中的 i 实际上又可以分为两部分：i′和 i″，而图 15.6 中的 e 是分送厂长与生产科长的，也可以分为 e′和е″两部分。通过对库存管理中各项业务的分析，又增添了两个数据存储和五个数据流。这两个数据存储是库存总帐和发料流水帐。这五个数据流是：k，进货登记；1，发料查库存；m，发料时存的领料单；n，月底结帐时处理领料单：o.用底结帐时更新库存量。

这样，我们对系统的描述又细致了一步。

这时图中的每一个模块，都是一项单独的业务了。如果我们前面已经有了各项业务的事务工作分析图，那么进一步的分解只不过是把事务工作分析图中的内容进一步抽象，并填入数据流图。这样，我们就可以得到如图 15.8 的第四层数据流图，限于篇幅，我们就不再对图中的数据流和数据存储进一步分析了。

按照这样的方法，我们可以继续分解下去，直到所需要的详细程度。分解的终点应按具体情况确定。一般来说，为了进行信息系统的分析及改造，应该在图上表示出所有重要的数据存储，同时，每一个处理模块的任务及处理原则应该能够用简便明确的语言具体表达出来。对于比较大的系统，为了能够看清楚整个系统的全貌，模块的划分可以粗一些，而把细节用局部的较详细的数据流图描述，即用一套有分有合的图来描述系统。

在绘制数据流图的时候，常常容易忽视的是各种错误情况及意外情况的处理。任何一个系统中，处理正常的业务总是比较容易的。如果我们在描述一个系统时，只描述了其中正常业务的处理过程，那么只算是描述了不到一半。错误情况和意外情况虽然很少出现，但是情况却是多种多样的，正常的情况则只有一种。作为系统必须处理的输入信息，每一种错误的输入和正确的输入是处于同等地位的。我们决不能因为错误和意外情况只占百分之一而忽视它们。对于各种错误及意外情况的识别、区分及处理，在各类系统中都占有十分重要的位置。在调查研究中，人们往往只调查和记录下来正常业务的处理过程，而忽略错误及意外情况的种类、出现频率、危害程度与处理方法。当我们把手工处理转变为计算机处理时，原系统中靠工作人员的经验或灵活性掩盖起来的不严密之处，就都会暴露出来，从而影响系统的正常工作。对于错误及意外情况的处理就属于这一类问题。因此，系统分析人员的重要责任就是掌握并确切地表达出积累于有经验的管理人员头脑中的处理原则及方法。

当然，任何系统没有必要也不可能处理所有的错误及意外情况，因为实际中的错误种类大多，而出现的频率又极不相同。因此，正确的做法应该是根据调查研究得到的素材，按照出现的频率程度及对系统影响的大小，选择最主要的几种错误情况及意外情况，描述其处理过程，对于其他各种情况则以“否则”或“其他错误”而加以统一的概括处理。例如“停止工作，显示错误信息，等待手工干预”。对于一些危害性不大的错误则可以忽略不计，继续运行。

总之，要注意错误及意外情况的处理，而做好这一分析的基础在于对系统进行调查时所收集的各种有关信息。

最后完成的数据流图是十分复杂的，应该有步骤地对所完成的图进行复核、誊清。复核可以从以下几方面去进行：

检查有关的外部实体。与系统有关的所有外部实体是否都已画入图内，每一个外部实体与系统的数据交换（包括送入系统的与由系统送出的）

是否有遗漏，这些数据交换的流向是否正确，即直接和哪项功能或数据存储相联系，每个箭头的内容是否明确。
检查各个数据存储。看这些数据存储是否确实需要，是否都有相应的处理模块把信息送进去，进行修改、调用内容等等。一般来说，每个数据存储都应该“有进有出”，即有数据流入它，也有数据由它流出来。如果发现某个数据存储是“有出无进”，就需要认真检查，因为这种情况是比较少见的，只有一些固定不变的索引、目录之类才可能出现这种情况，这些文件是系统研制时已经建立好的（如果这些目录和索引还需要修改的话，那也就需要有“进”了）。这时需要检查是否遗漏了数据流。至于“有进无出”或“无进无出”，那就更需要认真检查，如果不是在调查中遗漏了数据流，那就是找到了信息系统的毛病——信息资源没有得到充分利用或存在多余的没有必要的数据存储。

在对数据流进行复查时，主要是检查每个数据流的内容是否明确，同时要检查数据流的首尾两端在内容、时间、格式及表达方式上是否一致，在这种地方往往容易发现遗漏的数据存储或数据处理模块。在数据流图上虽然并不算出各个数据流的各种定量指标，但是在复查时可以顺便检查这些数据是否已经收集齐备，这些在以后都是要用到的。

对于各个数据处理模块，主要是检查是否已经确切地规定了它们的功能，然后判断它的输入和输出是否已经明确规定，有没有遗漏，即为了进行这一处理，所需的输入数据是否已经齐备，它处理所得的结果是否都已经送往适当的地点去继续处理或存储起来。

这一复查工作是不能闭门进行的，应该尽量与用户见面。数据流图与前几种图不同，它不是从用户那里调查来的第一手原始材料。它已经过了系统分析人员的分析和加工。从好的方面讲，它更反映实质，更加全面地反映了系统的全貌；从不好方面讲，它有可能掺杂了系统分析人员的主观想象，而偏离了实际情况。由于数据流图是描述系统的逻辑模型的最主要的工具，由于它将成为以后进行讨论、分析、提出改善措施的主要依据，因此，这一复查是十分必要的，必须认真进行。对于领导和各类管理人员，应该把与他们工作有关的信息系统状况提交给他们审阅，得到他们的补充、修改及认可，否则就有可能发生偏差。

数据流有两个明显的特点。第一是它的抽象性。它的高度抽象的图例记号使它能够舍弃具体的工作场所、处理手段、信息介质，从而把信息的流动与处理的过程跟物质的流动与处理完全分开，这就给信息系统的评价和改善创造了条件，打开了视野。第二个特点是它的综合性，它不是描述单项业务的处理过程，而是描述整个系统的综合流程。因而，从这个图上可以明确地看出各项业务的联系和相互制约的情况，各种数据存储的建立、更新及使用情况，从而给人们以整个系统的总体概念。

由于这两个特点，数据流图在调查研究的各种工具中占据了特殊的重要地位，必须认真地画好。