软件工程读书笔记.docx

1.软件危机在计算机软件的开发和维护过程中所遇到的一系列严重问题。2.软件危机的表现 软件成本日益增长 开发进度难以控制 软件质量差 软件维护困难 软件开发速度跟不上计算机发展速度3.软件危机的原因 技术原因 软件规模越来越大 软件复杂度越来越高 管理原因 软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性 对用户需求没有完整准确的认识，就匆忙着手编写程序4.软件工程1) 将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护。2) 对1)中方法的理论研究。5.生命周期软件生命周期由软件定义、软件开发和运行维护三个时期组成，每个时期又可进一步划分成若干个阶段，每个阶段有各自的任务。l 问题定义l 可行性分析l 需求分析l 概要设计l 详细设计l 编码和单元测试l 综合测试l 维护6.软件过程生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。7.瀑布模型 ：l 阶段间具有顺序性和依赖性l 推迟实现的观点l 质量保证的观点，文档驱动优点：文档驱动的规范坏，每个阶段的仔细验证。缺点：通过文档与客户沟通，最终产品可能不能真正满足客户需求。8.快速原型模型：n 快速建立起可以运行的程序，其功能往往是最终产品功能的子集。特点：通过原型系统获取客户要求，一旦需求确定，原型将被抛弃。9.增量模型：l 把软件产品作为一系列增量构件来设计、编码、集成和测试。优点：能在最早的时间把最新的功能提交给客户；减少客户对全新软件的冲击。缺点：开发困难，设计阶段必需有一个好的体系结构10.螺旋模型：l 在每个阶段之前都增加了风险分析过程的快速原型模型。优点：对可选方案和约束条件的强调有利于已有软件的重用；减少了过多测试或测试不足带来的风险；维护只是一个周期；风险驱动。11.瀑布模型：面向对象迭代无缝可行性分析1. 可行性分析任务l 技术可行性l 经济可行性l 操作可行性l 法律可行性2. 可行性分析过程n 复查系统规模和目标n 研究目前正在使用的系统n 导出新系统的高层逻辑模型n 进一步定义问题n 导出和评价供选择的解法n 推荐行动方针n 草拟开发计划n 书写文档提交审查3. 系统流程图 概括描绘物理系统的传统工具 用图形符号，以黑盒子形式描述组成系统的每个部件 程序、文档、数据库、人工过程3. 数据流图(DFD) 描绘信息流和数据从输入移动到输出的过程中所经受的变换。一图二图三图4. 数据字典l 关于数据的信息的集合，即对DFD图中包含的元素的定义的集合。l 数据字典的用途是供人查阅不了解的条目的解释。提供分析设计过程中关于数据的描述。需求分析5. ER模型ER图中包含实体(即数据对象)、关系和属性三种基本成分。6. 状态转换图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。7. IPO图：总体设计8. 耦合和内聚：松散耦合高内聚耦合衡量不同模块彼此间互相依赖(连接)紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。9. 层次图(H图)在层次图中一个矩形框代表一个模块，框间的连线表示调用关系(位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块)10. HIPO图=H图+IPO图11. 结构图a) 结构图中带注释的箭头表示模块调用过程中来回传递的信息。b) 尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。 判定为真时调用A，为假时调用B 模块M循环调用模块A，B，C 详细设计12. 结构化程序设计：如果一个程序的代码块仅仅通过顺序、选择和循环这三种控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。13. 系统流程图14. 盒图15. PAD图：16. 判定表：一张判定表由四部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。17. 判定树：判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系实现18. 实现=编码+测试19. 白盒测试：结构测试l 逻辑覆盖语句覆盖。每个语句判定覆盖。每个语句+每个分支条件覆盖。每个语句+每个判定表达式的每个条件判定/条件覆盖条件组合覆盖。每个判定表达式的每个条件的组合点覆盖（语句覆盖）边覆盖（判定覆盖）路径覆盖。每条路径l 控制结构测试基本路径测试：画流图。计算流图环形复杂度：节点数（出度大于2的点）+1 或 边-点+2确定线性独立路径的基本集合：独立路径至少包含一条在定义该路径之前不曾用过的边。复杂度是独立路径上界设计可强制执行基本集合中每条路径的测试用例。条件测试：循环测试：简单循环；嵌套循环；串接循环20. 黑盒测试：功能测试l 等价划分有效输入无效输入有效输出无效输出l 边界值分析选取刚好等于、稍小于和稍大于等价类边界值l 错误推测错误推测法在很大程度上靠直觉和经验进行。维护21. 软件维护：就是在软件已经交付使用之后，为了改正错误或满足新的需求而修改软件的过程。 改正性维护 适应性维护 完善性维护 预防性维护22. 软件的可维护性：维护人员理解、改正、改动或改进这个软件的难易程度。23. 决定软件可维护性的因素：a) 1.可理解性b) 2.可测试性c) 3.可修改性d) 4.可移植性e) 5.可重用性24. 可维护性复审：在软件工程过程的每个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。面向对象方法学引论25.面向对象有点：l 与人类习惯的思维方法一致l 稳定性好l 可重用性好l 较易开发大型软件产品l 可维护性好26.面向对象建模：l 描述系统数据结构的对象模型l 描述系统控制结构的动态模型l 描述系统功能的功能模型27.用例模型：用用例图建立起来的系统模型称为用例模型。用例模型描述的是外部行为者所理解的系统功能。用例模型的建立是系统开发者和用户反复讨论的结果，他描述了开发者和用户对需求规格所达成的共识。28.用例图包含的模型元素：系统。方框行为者。线条人用例。椭圆用例之间的关系，包括扩展和使用，都是泛化的两种不同形式。5连线29.用例是一个