SE03第3章结构化分析.pptVIP

* 软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 业务需求（business requirement）反映了组织机构或客户对系统或产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求（user requirement）描述了用户使用产品必须要完成的任务，可以在用例模型或方案脚本中予以说明。功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 * * * * */56 某学校教学管理ERD */56 教学数据模型 学号 姓名 专业 性别 …… 学生 职工号 姓名 专业 职称 年龄 教师 课程号 课程名 学分 学时 …… 课程 学号 课程号 成绩 选课 */56 第3章 结构化分析（Structured Analysis, SA） 结构化分析过程和准则 与用户通信获取用户需求的方法 分析建模与规格说明 实体-关系图 数据流图 状态转化图 数据字典 */56 3.5 数据流图（ Data Flow Diagram, DFD） 最初，结构化分析方法仅讨论数据流建模。目标系统被表示成如图所示的数据变换流程图。系统的功能体现在核心的数据变换中。 外部实体 外部实体 外部实体 外部实体 目标 系统 输入信息 输入信息 输出信息 输出信息 */56 功能建模与数据流图 功能建模的基本思想： 用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。 功能模型： 使用 DFD 来表达数据流从输入到输出的移动变换过程。 */56 数据流图（DFD） DFD从信息传递和处理的角度，以图形的方式描绘信息流和数据从输入移动到输出的过程中所经受的变换 DFD可以按自顶向下、逐步分解的方法表示内容不断增加的数据流和功能细节 DFD中没有物理元素，是系统逻辑功能的图形表示 DFD既提供了功能建模的机制，也提供了信息流建模的机制，从而可以建立起系统或软件的功能模型 */56 3.5.1 数据流图符号四种基本符号及其含义 */56 表明多个数据流与加工之间关系的符号 */56 分层DFD */56 */56 */56 3.5.2 DFD例子：定货系统 (需求描述) 一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。 每个需要再次定货的零件应列出下述数据：零件编号、零件名称、定货数量、目前价格、主要供应者、次要供应者。 零件入库或出库称为事务，通过放在仓库中的终端将事务报告给定货系统。当某种零件的库存量少于库存量临界值时就应该再次定货。 */56 完成DFD的步骤及要点 从问题描述中提取DFD的四种成分： 数据源点和终点 处理（加工） 数据流和存储 不是所有数据存储和数据流都能直接从问题描述中提取出来 按自外向内、自顶向下、逐层细化、完善求精的方法画出DFD 当进一步分解涉及如何具体实现一个功能时就不应该再分解了 对DFD层细化时必须保持信息连续性 */56 表3.1 */56 基本系统模型 */56 功能级数据流图 */56 系统主要功能进一步细化后的DFD */56 3.5.3 命名 数据流和数据存储（名词或名词性短语） 名字应代表其整个内容而非其某些成分 不使用空洞的、缺乏具体含义的名字 处理（及物动词＋宾语） 先为数据流命名，再为与之关联的处理命名 名字应反映整个处理的功能而非其部分功能 仅包含一个动词，否则应分解处理 数据源点/终点（问题域习惯使用的名词） */56 第3章 结构化分析（Structured Analysis, SA） 结构化分析过程和准则 与用户通信获取用户需求的方法 分析建模与规格说明 实体-关系图 数据流图 状态转化图 数据字典 */56 3.6 状态转换图（ STD ） STD：通过描述系统的状态及引起系统状态转换的事件，来表示系统的行为。 状态：任何可以被观察到的系统行为模式，它规定了系统对事件的响应方式。 一个状态代表系统的一种行为模式。 事件：引起系统状态转换的控制信息。 系统对事件的响应：动作或改变系统状态 */56 STD 符号表示 圆形或椭圆形框---系统状态（框内