4可行性之数据字典.ppt

* SA方法采用“分解”的方式来理解一个复杂的系统，“分解”需要有描述的手段，数据流图就是作为描述“分解”的手段引进的。 对大多数数据处理系统来说，从数据流的角度来描述一个企事业组织的业务活动是比较合适的。数据流图描述了一个组织有哪几个组成部分，也描述了来往于各部分之间的数据流。 ? * 我们可以用图3.2的数据流图描述这个系统的“分解”。这张图告诉我们：系统分解成“收集”、“分类”、“报名”．．．．．·等8个部分，这些部分之间通过图中所示的数据流进行联系。要理解整个系统只需分别理解这8个部分就可以了。由于每个部分比整个系统小多了，所以分析工作就可简化。 * 1.数据流可以从加工流向加工，也可以从加工流向文件或从文件流向加工，也可以从源点流向加工或从加工流向终点。见图3.3。 ? 2.两个加工之间可以有几股数据流，如图3.4所示，日报表和月报表这两个数据流相互间没有任何联系，也不是同时流出的。 ? 3.一般说，除了流向文件或从文件流出的数据流不必命名之外(在这种情况下，有文件名就足够了），每个数据流必须有一个合适的名字。名字一方 面是为了 区别，同时也是给人一个直观的印象，使人容易理解这个数据流的含义。为数据流命名时，可从其组成成分或含义的角度来考虑，如 图 3.5中，“取款单”和“合理取款单”的组成是相同的，但后者是经检查后认为合理的(如它的“账号”和“户名”相符)，这样的命名就易于理解。 * 1.应该注意的是，数据流图中描述的是数据流而不是控制流。图 3.6中“取下一张卡片”是一个控制流而不是数据流，因为并没有任何数据沿着这个箭头流动，所以这个箭头应该从图中删去。习惯使用框图(程序流程图)的软件人员特别应该注意不要犯这种错误。 2.图3.7中“每月第一天”是加工“计算工资”的激发条件，它也不是数据流，因为并没有数据流经它，所以也应删去。 3.注意加工与文件之间数据流的方向，如果加工要读文件，则数据流是从文件流出的，如果加工要写文件或修改文件(虽然修改文件一般先要读文件，但其本质是写)则数据流是 流向文件的，如果加工既要读文件(除了修改文件之外)又要写文件，则数据流是双向的。图3.8中，加工“检查拼写的正确性”对输入的词进行检查，当在词汇表中查不到这个词时，则认为这个词是错误的加以拒绝，由于这个加工只读词汇表，所以图中的箭头从文件流出。如果这个加工从词汇表中查不到输入的词时，认为这是一个新的词，并将它增添到词汇表中，则加工与文件间的箭头应画成双向的。 * 应注意的问题： ?????1.适当地命名 数据流图中每一成分的命名是否恰当与数据流图的易理解性有直接的关系，所以命名时应该仔细推敲。 2. 画数据流而不是控制流 数据流图与传统的框图是不同的，数据流图是从数据的角度来描述一个系统，而框图则是从对数据进行加工的工作人员的角度来描述系统。数据流图中的箭头是数据流，而框图中的箭头则是控制流，它表达的是程序执行的次序。 在宏观地分析一个组织的业务概况时从数据流的角度来理解问题比较合适，所以采用数据流图，而框图只适用于描述系统中某个加工的执行细节。 数据流图中强调数据流而不强调控制流，所以从图中一般是看不出执行次序的，例如图3.2中，我们看不出“产生发票”这个加工是每接收到一张“报名单”就进行工作，还是每天工作一次，这个问题可推迟至建立“小说明”时才加以考虑。 ? 为了区别数据流和控制流，我们只需问一个问题：“这条线上有什么数据流过？”，如果没有，它就是控制流，在数据流图中就不应将它画出。 3.先考虑稳定状态 ? 画数据流图时，暂不必考虑系统是如何开始工作的、如何结束的，只假定它能开始运行就是了，这是为了集中精力先考虑稳定状态下的种种问题，所以将系统的“开始”和“结束”等问题推迟到适当的时候才予以考虑 。 4.忽略琐碎的枝节 ? 画数据流图时，应集中精力于主要的数据流，而暂不考虑一些例外情况、出错处理等枝节性问题。我们只需在图中画出这些枝节性数据流就可以了〔如图3.2中的数据流“不合理)，而不必沿着它们再进一步分析下去。虽然大多数系统都要花较多的精力来考虑例外情况、出错处理等，但这些问题对理解整个系统并没有很大的影响，因此可以放心地推迟考虑。 5.随时准备重画 ? 理解一个问题总要经过从不正确到正确，从不恰当到恰当的过程，一次就成功的可能性是很小的，对复杂的问题尤其如此，分析员应随时准备抛弃旧的数据流图而用更好的版本来代替它，在分析阶段重画几张图是很小的代价，只要能获得更正确清晰的需求说明书，使得设计、编程等阶段节省大量的劳