软件工程课件第3章节.ppt

3 .1 .1 确定对系统的综合要求;2．系统性能要求 ;3．1．2 分析系统的数据要求 ;3．1．3 导出系统的逻辑模型 ;第三章 需求分析;需要重点掌握的：; 定义时期： 问题定义 可行性研究 需求分析 开发时期： 总体设计 （设计） 详细设计 编码和单元测试 综合测试 维护时期： 软件维护;(1) 理解描述问题的信息域，建立数据模型（E-R图）。 (2) 定义软件应完成的功能，建立功能模型（数据流图+数据字典）。 (3) 描述作为外部事件结果的软件行为，建立行为模型（状态转换图）。 (4) 对描述信息、功能和行为的模型，用层次的方式展示细节。 ;1．确定对系统的综合要求 2．分析系统的数据要求 3．导出系统的逻辑模型 4．修正系统的开发计划;3．2 与用户沟通获取需求的方法 ; 3．2．1 访谈 ;3．2．2 面向数据流自顶向下求精 ; 是一种面向团队的需求收集方法。 分析需求的过程： ? 由开发者和用户分别写出“产品需求”； ? 针对每个议题创建意见一致的列表； ? 为每张列表中的项目制定小型规格说明，制定出产品的确认标准 ; ? 创建出意见一致的确认标准。起草完整的软件需求规格说明书。 ; 目的： 尽快提供可运行的目标系统的模型，以使用户和开发者在 “做什么”这个问题上尽可能快地达成共识。 要点： 实现用户看得见的功能，省略目标系统的“隐含”功能。 应具备的特性： “快速”、“容易修改” ;常用的方法和工具：;3．3 分析建模与规格说明 ;3．4 实体-联系图;1;L;E-R图：;商店（商店号, 商店名, 地址, 经理） 职工（职工号, 姓名,性别,商店号,来店时间） 商品（商品号, 商品名, 产地, 价格) 销售（职工号,商品号, 销售数量） 经营（商品号,商店号，月销量）;3．5 数据规范化 ;例：描述学校的数据库： 学生的学号（Sno）、所在系（Sdept） 系主任姓名（Mname）、课程号（Cno） 成绩（Grade）; ⒉ 更新异常 数据冗余 ，更新数据时，维护数据完整性代价大。 例：某系更换系主任后，系统必须修改与该系学生有关的每一个元组;⒊ 插入异常 该插的数据插不进去 例，如果一个系刚成立，尚无学生，我们就无法把这个系及其系主任的信息存入数据库。 ⒋ 删除异常 不该删除的数据不得不删 例，如果某个系的学生全部毕业了， 我们在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。;结论： Student关系模式不是一个好的模式。 “好”的模式： 不会发生插入异常、删除异常、更新异常，数据冗余应尽可能少。 原因： 由存在于模式中的某些数据依赖引起的。 ; 属性组U上的一组函数依赖: F ＝｛ Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade ｝;即：对上述关系模式，通过投影，分解为 如下三个关系模式： 学生：S(SNO,SDEPT) SNO→SDEPT ； 选课：SG(SNO,CNO,G) (SNO,CNO)→G； 系：DEPT(SDEPT,MNAME) SDEPT→MNAME ； 所有的异常都会得到解决。; 规范化就是将较低一级范式的关系模式通过分解，转换为若干个较高一级范式的关系模式集合。;计算机储蓄系统数据流图;计算机储蓄系统的实体-联系图;3．6 状态转换图 ;状态1 状态变量1 活动表1;活动表的语法格式： 事件名 / 动作表达式 常使用的标准事件名有： entry: 指定进入该状态的动作 do： 指定在该状态下的动作 exit: 指定退出该状态的动作;电梯的状态转换图;;取消;白方;用完CPU时间;3．7 其它图形工具 ; 用树型结构描绘数据的层次结构。 ;文件管理 ;层次方框图与层次结构图的区别;3．7．2 Warnier图 ;3．7．3 IPO图 ;改进的IPO图（表）：;3．8 验证软件需求 ;? 用于需求分析的软件工具;（1）描述任何应用领域的信息系统。 （2）创建数据库，保存对系统的描述符。 （3）对描述符施加增、删、改操作。 （4）产生格式化文档及各种分析报告。;本章小结 ; ? 访谈 ? 面向数据流自顶向下求精 ? 面向团队的需求收集法 ? 快速原型法 ? 建立模型的方法; ? 软件需求规格说明书 ? 数据流图 ? 实体-联系图 ? 状态图