数据流图中每个成分的命名是否恰当,直接影响数据流图的可理解性。因此,给这些成分起名字时应该仔细推敲。
命名
1.为数据流(或数据存储)命名
(1)名字应代表整个数据流(或数据存储)的内容,而不是仅仅反映它的某些成分。
(2)不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。当标而
(3)如果在为某个数据流(或数据存储)起名字时遇到了困难,则很可能是因为对数据流图分解不恰当造成的,应该试试重新分解,看是否能克服这个困难。
2.为处理命名
(1)通常先为数据流命名,然后再为与之相关联的处理命名。这样命名比较容易,而且体现了人类习惯的“由表及里"的思考过程。
(2)名字应该反映整个处理的功能,而不是它的一部分功能。
(3)名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。
(4)通常名字中仅包括一个动词,如果必须用两个动词才能描述整个处理的功能,则把这个处理再分解成两个处理可能更恰当些。
(5)如果在为某个处理命名时遇到困难,则很可能是发现了分解不当的迹象,应考虑重新分解。
数据源点/终点并不需要在开发目标系统的过程中设计和实现,它并不属于数据流图的核心内容,只不过是目标系统的外围环境部分(可能是人员、计算机外部设备或传感器装置)。通常,为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如“采购员”、“仓库管理员”等)。
用途
画数据流图的基本目的是利用它作为交流信息的工具。分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来,供有关人员审查确认。由于在数据流图中通常仅仅使用4种基本符号,而且不包含任何有关物理实现的细节,因此,绝大多数用户都可以理解和评价它。
从数据流图的基本目标出发,可以考虑在一张数据流图中包含多少个元素合适的问题。一些调查研究表明,如果一张数据流图中包含的处理多于5~9个,人们就难于领会它的含义了。因此数据流图应该分层,并且在把功能级数据流图细化后得到的处理超过9个时,应该采用画分图的办法,也就是把每个主要功能都细化为-张数据流分图,而原有的功能级数据流图用来描绘系统的整体逻辑概貌。
数据流图的另一个 主要用途 是作为分析和设计的工具。 分析员在研究现有 的系统时常用系统流程图表达他对这个系统的认识,这种描绘方法形象具体,比较容易验证它的正确性;但是,开发工程的目标往不是完全复制现有的系统,而是创造一个能够完成相同的或类似的功能的新系统。用系统流程图描绘一个系统时,系统的功能和实现每个功能的具体方案是混在一起的。 因此,分析员希望以另一种方式进 一 步总结现有的系统,这种方式应该着重描绘系统所完成的功能而不是系统的物理实现方案。数据流图是实现这个目标的极好手段。
当用数据流图辅助物理系统的设计时,以图中不同处理的定时要求为指南,能够在数据流图上画出许多组自动化边界,每组自动化边界可能意味着一个不同的物理系统,因此可以根据系统的逻辑模型考虑系统的物理实现。例如,考虑下图,事务随时可能发生,因此处理1.1(“接收事务”)必须是联机的;采购员每天需要一次订货报表,因此处理2(“产生报表”)应该以批量方式进行。问题描述并没有对其他处理施加限制。
例如,可以联机地接收事务并放人队列中,然而更新库存清单、处理订货和产生报表以批量方式进行(下图)。当然,这种方案需要增加一个数据存储以存放事务数据。
这种划分自动化边界的方法暗示以批量方式更新库存清单
改变自动化边界,把处理1.1,1.2和1.3放在同一个边界内,这个系统将联机地接收事务、 更新库存清单和处理订货及输出订货信息;然而处理2将以批量方式产生订货报表。还能设想出建立自动化边界的其他方案吗?如果把处理1. 1和处理1.2放在一个自动化边界内,把处理1.3和处理2放在另一个边界内,意味着什么样的物理系统呢?
另一种划分自动化边界的方法建议以联机方式更新库存清单
数据流图对更详细的设计步骤也有帮助,从数据流图出发映射出软件结构的方法——面向数据流的设计方法