第四章需求分析.ppt

软件工程 - 2011 - 第四章 软件需求 源点和终点 源点和终点是系统之外的实体，可以是人、物或其他软件系统。源点和终点是为了帮助理解系统接口而引入的。 加工/变换 对数据进行处理的单元。在分层数据流图中，要对加工进行编号，以便于管理。加工也要选取适当的名字，以提高数据流图的易读性。 数据流 由一组数据项组成。例如，数据流“订票单”由姓名、住址、电话、航班号、日期、始点、终点等数据项组成；数据流“航班”由航班号、日期和姓名等数据项组成 数据流可以从加工流向加工，如“航班”、“费用”；可以从源点流向加工，或从加工流向终点；可以从加工流向数据存储或从数据存储流向加工 文件 用来暂时存储数据的。如果加工要读文件，则数据流的方向是从文件到加工；如果加工要写文件，则数据流的方向是从加工到文件；如果加工既要读文件又要写文件，则数据流的方向是双向的 假设一家工厂的采购部每天需要一张定货报表， 报表按零件编号顺序，表中列出所有需要再次定 货的零件。对于每个需要再次定货的零件应该列 出下列数据：零件编号，零件名称，定货数量， 目前价格，主要供应者，次要供应者。零件入库 或出库称为事务，通过放在仓库中的CRT终端把 事务报告给定货系统。当某种零件的库存量少于 库存量临界值时就应再次定货。 把基本系统模型加上源点和终点作为顶层数据流图 画数据流图不是画流程图 父图和子图的平衡问题 局部文件的问题 分解的深度和层次问题 命名问题 文件(数据存储)总是局部于分层数据流图的某一层或某几层,所以数据流图中引入的文件都是局部文件 一个加工的分解最好不要超过7（9）个子加工。超过七个时，可以用增加层次，减少子加工数的方法。 分解在逻辑上应合理、自然，不能硬性分割。也就是说，要根据问题的逻辑特性进行分解。 在保证数据流的易理解的前提下，尽量减少分解层次。这样可以减少层次的界面。 分解要均匀。即在一张数据流图中，不要有这样的情况：有些加工已是基本加工，另一些加工还要分解好几层，但绝对均匀不可能，不要相差太大 数据流命名 名字应代表整个数据流（有时也会把现实环境中传递的一组数据中最重要的那个数据的名字作为数据流的名字） 数据流命名（续） 现实环境中，传递的一些表格、单据的名字可以直接作为数据流的名字。 数据流命名（续） 不要使用空洞的、缺乏具体含义的名字 不要把控制流作为数据流。 如果在为某个数据流命名时遇到困难，可能是数据流图分解不当，应考虑重新分解DFD 加工（处理）命名 顶层的加工名可以是软件项目的名字 不要使用空洞的、缺乏具体含义的名字 通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程 如果在为某个加工命名时遇到困难，可能是数据流图分解不当，应考虑重新分解DFD 加工（处理）命名（续） 加工的名字最好由一个谓语动词加上一个宾语组成。如“计算运费”、“准备机票”。也可以把宾语和谓语动词颠倒书写。如“运费计算”、“机票准备” 名字应该反映整个处理的功能，而不是它的一部分功能 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些 作为交流信息的工具 作为分析和设计的工具 用数据流图辅助物理系统的设计时，以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界，每组自动化边界可能意味着一个不同的物理系统，因此可以根据系统的逻辑模型考虑系统的物理实现 可以从数据流图出发映射出软件结构 数据字典是对数据流图中包含的所有元素的定义的集合 数据词典与数据流图共同构成系统的逻辑模型 数据字典应该由对下列4类元素的定义组成：数据流、数据流分量(即数据元素)、数据存储、处理 数据流是数据结构在系统内传播的路径。一个数据流词条应有以下几项内容： 数据流名： 说明：简要介绍作用即它产生的原因和结果； 数据流来源：来自何方； 数据流去向：去向何处； 数据流组成：数据结构； 每个数据量的流通量：数据量，流通量； 定义绝大多数复杂事物的方法，都是用被定义的事物的成分的某种组合表示这个事物，这些组成成分又由更低层的成分的组合来定义。 顺序 即以确定次序连接两个或多个分量 选择 即从两个或多个可能的元素中选取一个 重复 即把指定的分量重复零次或多次 可选 即一个分量是可有可无的(重复零次或一次) 符号 含义 举例 ＝ “被定义为” ＋ 与 x=a＋b，x由a和b组成 [... , ...] 或 x=[a , b]， x由a或由b组成 [...|...]