1. 1. 第一章
    1. 1.0.1. 1.1.1 软件的定义
      1. 1.0.1.1. 软硬件失效图：
    2. 1.0.2. 1.1.3 遗留软件
  • 2. 第二章
    1. 2.0.1. 2.1 定义软件工程学科
      1. 2.0.1.1. 层次结构定义：
    2. 2.0.2. 2.2.1 过程框架
    3. 2.0.3. 2.2.2 普适性活动
    4. 2.0.4. 2.4 软件开发神话 （判断题）
  • 3. 第三章
    1. 3.0.1. 3.1 通用过程模型
      1. 3.0.1.1. 过程流
  • 4. 第四章 过程模型
    1. 4.0.1. 4.1 惯用过程模型
    2. 4.0.2. 4.2 专用过程模型
    3. 4.0.3. 4.2.1 基于构件的开发
    4. 4.0.4. 4.2.2 形式化方法模型
    5. 4.0.5. 4.2.3 面向方面的软件开发
    6. 4.0.6. 4.3 统一过程 UP
  • 5. 第五章 敏捷开发
    1. 5.0.0.1. 敏捷开发宣言
  • 5.0.1. 5.3 敏捷及变更成本
  • 5.0.2. 5.4 极限编程 XP
    1. 5.0.2.1. 5.4.1极限编程过程
    2. 5.0.2.2. 5.4.2 工业极限编程 IXP
  • 6. 第六章 软件工程的人员方面
    1. 6.0.1. 6.4 团队结构
  • 7. 第七章 理解需求
    1. 7.0.1. 7.1 需求工程
    2. 7.0.2. 7.3.2 质量功能部署 QFD
    3. 7.0.3. 7.5 分析模型的元素
  • 8. 第八章 基于场景的需求建模
    1. 8.0.0.1. 用例图的包含与拓展
    2. 8.0.0.2. 用例图中参与者与泛化关系
  • 8.0.1. 8.3 活动图
  • 8.0.2. 8.4 泳道图
    1. 8.0.2.1. 活动图与泳道图的区别：
  • 9. 第九章 基于类的需求建模
    1. 9.0.1. 9.1 识别分析类 / 语法分析
    2. 9.0.2. 9.4 CRC / 类-职责-协作者 建模
      1. 9.0.2.1. 类之间的通用关系
      2. 9.0.2.2. 类关联关系
  • 10. 第十章 需求建模：行为和模式
    1. 10.0.1. 10.2 识别用例事件
    2. 10.0.2. 10.3 状态表达
      1. 10.0.2.1. 1. 状态图
      2. 10.0.2.2. 2. 顺序图
  • 11. 第十一章 设计概念
    1. 11.0.1. 11.2.1 质量属性
    2. 11.0.2. 11.3 设计概念间的区别
    3. 11.0.3. 11.3.10 重构
    4. 11.0.4. 11.3.12 组织良好的设计类的四个特征
  • 12. 第十二章 体系结构设计
    1. 12.0.1. 12.3.1 体系结构风格的简单分类
  • 13. 第十三章 构件级设计
    1. 13.0.1. 13.1 构件
    2. 13.0.2. 13.1.1 面向对象观点
    3. 13.0.3. 13.1.2 传统观点
    4. 13.0.4.
    5. 13.0.5. 13.2.1 构件的基本设计原则 SOLD
      1. 13.0.5.1. 构件打包原则：
    6. 13.0.6. 13.2.3 内聚性
    7. 13.0.7. 13.2.4 耦合性
    8. 13.0.8. 面向对象编程实际上要求面向接口编程
  • 14. 第十四章 用户界面设计
    1. 14.0.1. 14.1 黄金规则
  • 15. 第十五章 质量概念
    1. 15.0.1. 15.2 软件质量
    2. 15.0.2. 15.3 软件质量困境
      1. 15.0.2.1. “足够好的软件”
    3. 15.0.3. 15.3.2 质量的成本
      1. 15.0.3.1. 从预防道检查内部失效成本和外部失效成本，找到并修复的相关成本会急剧增加
  • 16. 第十七章 软件测试策略
    1. 16.0.1. 17.1.3 传统软件的测试步骤
      1. 16.0.1.1. 测试人员参与项目的时机
  • 17. 第十八章 项目管理
    1. 17.0.1. 22.1 管理的范围 4P
  • 18. 已知题目
    1. 18.0.1. 选择：
    2. 18.0.2. 判断：
    3. 18.0.3. 材料分析题：
    4. 18.0.4. 名词解释：
    •

    软件工程

    (Updated: )
    考试

    第一章

    1.1.1 软件的定义

    1. 指令的集合
    2. 数据结构
    3. 软件描述信息

    软硬件失效图：

    IMG_20201219_170723

    软件每次变更都会引入新的错误，可以说不断的变化是软件退化的根本原因

    1.1.3 遗留软件

    1. 维护代价高昂且系统演化风险较高
    2. 生命周期长且业务关键性
    3. 质量差，设计难以扩展，代码令人费解

    最合理的方法也许是什么也不做

    第二章

    2.1 定义软件工程学科

    将系统化的、规范的、可量化的方法应用于软件开发中、运行、维护中，将工程化的方法运用到软件中

    层次结构定义：

    由上到下：工具 -> 方法 -> 过程 -> 质量关注点

    IMG_20201219_170736
    1. 支持软件工程的根基在与质量关注点
    2. 软件工程的基础是过程层，软件过程将各个技术层次的结合在一起，使得合理及时的开发软件成为了可能
    3. 软件工程方法为构建软件提供技术上的解决方法
    4. 软件工程工具为工程和方法提供自动化或半自动化的支持

    2.2.1 过程框架

    一个通用的过程框架包含以下五个过程

    1. 沟通：与客户沟通，理解项目目标，收集需求以定义软件特性和功能
    2. 策划：创建一个“地图”，定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划
    3. 建模：利用模型更好的理解软件需求，并完成符合这些需求的软件设计
    4. 构建：编码和测试
    5. 部署：交付用户，对其评测并反馈意见

    2.2.2 普适性活动

    普适性活动贯穿软件项目始终

    典型普适性活动如下：

    • 软件项目跟踪和控制：评估项目进度
    • 风险管理
    • 软件质量保证
    • 技术评审：尽量在错误传播到下一个活动之前发现并解决
    • 测量：帮助团队在发布式满足要求
    • 软件配置管理
    • 可复用管理
    • 工作产品的准备和生产

    2.4 软件开发神话 （判断题）

    软件开发神话，即关于软件及其开发过程的一些被人们盲目相信的说法。

    神话1：我们已经有了一本写满软件开发的标准和规程的宝典，难道不能提供我们所需要了解的所有信息吗？

    神话2：如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度。

    神话3：如果决定将软件外包给第三方公司，就可以放手不管，完全交给第三方公司开发。

    神话4：有了对项目目标的大概了解，便足以开始编写程序，可以在之后的项目开发过程中逐步充实细节。

    神话5：虽然软件需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。

    神话6：当我们完成程序并交付使用之后，我们的任务就完成了。

    神话7：直到程序开始运行，才能评估其质量。

    神话8：对于一个成功的软件项目，可执行程序是唯一可交付的工作成果。

    神话9：软件工程将导致我们产生大量无用文档，并因此降低工作效率。

    第三章

    3.1 通用过程模型

    过程流

    • 线性过程流

    • 迭代过程流

    • 演化过程流

    • 并行过程流

    IMG_20201219_170749

    第四章 过程模型

    4.1 惯用过程模型

    1. 瀑布模型

      瀑布模型的一个变体— V模型

    2. 增量模型

    3. 原型模型

    4. 螺旋模型

    4.2 专用过程模型

    4.2.1 基于构件的开发

    具有许多螺旋模型的特点，它的本质是演化模型，以迭代的方式构建软件，不同的是采用预先打包的软件构件来开发应用（调SDK）

    4.2.2 形式化方法模型

    主要是生成计算机软件形式化的数学规格说明

    一个选择题答案：形式化方法

    4.2.3 面向方面的软件开发

    为定义、说明、设计和构建方面提供过程和方法，是对横切关注点进行局部表示的一种机制，超越了子程序和继承的方法。

    横切关注点：如果某个关注点涉及系统多个方面的功能、特性和信息，这些关注点通常称为横切关注点。

    4.3 统一过程 UP

    IMG_20201219_170759

    统一过程的阶段与通用过程框架相通

    1. 起始阶段：包括沟通和策划
    2. 细化阶段：包括策划和建模 ？
    3. 构建阶段：与通用过程框架相同
    4. 转换阶段：包括构建和部署
    5. 生产阶段：增量生产

    第五章 敏捷开发

    敏捷开发宣言

    • 个人和他人之间的交流胜过开发过程和文档
    • 可运行的软件胜过宽泛的文档
    • 客户合作胜过合同谈判
    • 对变更的良好响应胜过按部就班的计划

    5.3 敏捷及变更成本

    IMG_20201219_170808

    5.4 极限编程 XP

    5.4.1极限编程过程

    它是敏捷开发中使用最广泛的一种方法

    IMG_20201219_170710

    策划 -> 设计 -> 编码 -> 测试

    1. 策划：收集用户故事（需求），了解开发软件所需的功能和特性
    2. 设计：遵守 Keep It Simple 原则，不鼓励额外功能设计，鼓励使用CRC卡
    3. 编码：开发一系列用于检测本次发布的所有故事的单元测试；结对编程指的是XP建议两个人为同一个故事开发，以保证实时解决问题和代码及时复审
    4. 测试：每当代码修改之后，及时进行回归测试，使用通用测试集，便于每天都可以进行系统集成和确认测试

    5.4.2 工业极限编程 IXP

    IXP 是 XP 的进化，它由XP的最低要求、以客户为中心和测试驱动精神组成

    两者区别：IXP管理具有更大的包容性，他扩大了用户角色，升级了技术实践

    第六章 软件工程的人员方面

    6.4 团队结构

    软件工程团队的四种模式

    1. 封闭模式：组成的团队遵循传统的权力层级模式，在做和以前相似的软件时效果很好，但是缺乏创新性
    2. 随机模式：团队是松散的，依靠团队成员的个人自发性，在需要创新和技术性突破式可以做的很优秀，但是很难保持有“秩序的操作”
    3. 开放模式：既有封闭模式的可控性，又有随机模式的创新性，适合解决复杂的问题，但是效率不高
    4. 同步模式：依赖于问题的自然区分，不需要过多的交流就能将成员组织在一起解决问题

    第七章 理解需求

    7.1 需求工程

    致力于不断理解需求的大量任务和技术，开始于沟通并持续到建模活动

    7项任务：

    1. 起始：建立基本的需求，包括存在的问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员初步达成交流合作的效果
    2. 获取：建立商业目标，建立优先机制和潜在架构的合理性
    3. 细化：将起始和获取阶段的信息进行拓展个提炼
    4. 协商：若有用户提出了过高的要求，或不同客户间的需求相互冲突，通过协商阶段来进行调解
    5. 规格说明：文档、图形化模型、形式化数学模型、使用场景等中的一个
    6. 确认：对需求工程的工作产品进行质量评估
    7. 需求管理：帮助项目组在项目进展中表示、控制和跟踪需求以及需求变更的活动

    PS：软件需求规格说明书/SRS：在项目商业化之前必须建立的详细描述软件各个方面的工作产品

    7.3.2 质量功能部署 QFD

    QFD是一种将用户需求转化为软件需求的技术

    分为3个需求：

    1. 常规需求：若这些需求存在，用户会满意
    2. 期望需求：客户没有清晰表达的基础功能，但是缺少了客户会不满
    3. 兴奋需求：超出客户需求，当这些需求存在时客户会很满意

    SafeHome 住宅安全系统UML用例图

    IMG_20201221_151815

    7.5 分析模型的元素

    1. 基于场景的元素：从用户的角度描述系统
    2. 基于类的元素：每个使用场景都意味着当一个参与者和系统交互时所操作的一组对象
    3. 行为元素：状态图是一种表现系统行为的方法
    4. 数据流元素

    第八章 基于场景的需求建模

    开发用例图时应列出特定参与者执行的活动和功能

    用例图包括：参与者、用例、系统边界、箭头

    SafeHome系统的初步用例图

    IMG_20201220_233123

    用例图的包含与拓展

    1. 包含：箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为

      image-20201221150418167

    2. 拓展：箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基用例。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。

      image-20201221150425638

      用例图中参与者与泛化关系

      发出箭头的事物“is a”箭头指向的事物。泛化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般一方。特殊一方继承了一般方的特性并增加了新的特性。

      image-20201221150517998

    8.3 活动图

    活动图在特定场景内通过提供迭代流的图形化表示来补充用例

    通过互联网访问摄像机监视设备并显示摄像机视图功能的活动图

    IMG_20201220_233120

    8.4 泳道图

    允许建模人员表示用力所示描述的活动流，同时指出参与者或分析类负责由活动举行所描述的活动。

    通过互联网访问摄像机监视设备并显示摄像机视图功能的泳道图

    IMG_20201220_233112

    活动图与泳道图的区别：

    ​ 在泳道图中，活动被按职责分配到用线分开的不同区域（泳道）

    第九章 基于类的需求建模

    9.1 识别分析类 / 语法分析

    ​ 检查需求模型开发的使用场景，并对系统开发的用例进行“语法解析”，即可开始识别类分析。带有下划线的每个名词可以确定为类，将这些名词输入到一个简单表中并标出同义词。如果要求某个类实现一个解决方案，那么这个类就是解决方案空间的一部分；否则，如果只要求某个类描述一个解决方案，那么这个类就是问题空间的一部分。

    9.4 CRC / 类-职责-协作者 建模

    实际上时表示类的标准索引卡片的集合。这些卡片分为三部分，顶部写类名，主体左侧列出类的职责，右侧写类的协作者

    • 类：
      • 实体类：代表保存在数据库中和贯穿在应用程序中的事务
      • 边界类：用于创建用户可见的何在使用软件交互的接口，职责是管理实体对象呈现给用户的方式
      • 控制类：是管理“工作单元”，
    • 职责：类似功能
    • 协作：当实现某个职责需要和其他类进行交互就有协作

    类之间的通用关系

    1. is-part-of
    2. has-knowledge-of / 有…知识：当一个类必须从另一个类获取信息时
    3. depends-upon / 依赖

    类关联关系

    1. 两个分析类以某种方式相互联系，在UML中，这些联系被称作关联。
    2. “一个或多个”使用1..表示，“0个或多个”使用0..表示。在UML中，星号表示范围无上界。

    第十章 需求建模：行为和模式

    10.2 识别用例事件

    系统和参与者之间交换了信息就发生了事件，事件时已交换信息的事实

    10.3 状态表达

    • 主动状态：对象进行持续变换或处理时的当前状态
    • 被动状态：某个对象所有属性的当前状态

    1. 状态图

    一种行为图，呈现了主动状态和导致这些主动状态发生的事件

    ControlPanel状态图

    IMG_20201220_233039

    箭头表示某个对象从一个主动状态转移到另一个主动状态，箭头上的标注是转移事件

    2. 顺序图

    表明事件如何引发从一个对象到另一个对象的转移，顺序图的重点在消息序列上，表示了对象之间传送消息的时间顺序。

    SafeHome 安全功能顺序图

    注意两者区别

    第十一章 设计概念

    11.2.1 质量属性

    • 功能性
    • 易用性
    • 可靠性
    • 性能
    • 可维护性 / 可支持性

    11.3 设计概念间的区别

    每一种概念都软件设计者应用更加复杂的设计方法提供了基础。每种方法都有助于：定义一套将软件分割为独立构建的标准，从软件的概念表示中分离出数据结构的细节，为定义软件设计的技术质量建立统一标准。

    11.3.10 重构

    一种重新组织的技术，可以简化构建的设计而无需改变其功能和行为

    定义：一种不改变代码的外部行为而是改进其内部结构的软件系统过程

    11.3.12 组织良好的设计类的四个特征

    1. 完整性与充分性：完整的封装所有可以合理遇见的存在于类中的属性和方法
    2. 原始性：一个类相关的方法应关注于实现类的某一个服务，不为同一职责提供两种方法
    3. 高内聚性：具有小而集中的职责机制，并且关注于使用属性和方法来实现这些职责
    4. 低耦合性：将类间的合作保持在一个可以接受的小范围内

    第十二章 体系结构设计

    12.3.1 体系结构风格的简单分类

    1. 以数据为中心的体系结构：数据存储位于这种体系结构的中心，其他构件会经常访问数据存储

      IMG_20201220_233000

    2. 数据流体系结构调用和返回体系结构：输入数据经过一系列计算构建和操作构件的变换形成输出数据

      IMG_20201220_233003

    3. 调用和返回体系结构

      1. 主程序 / 子程序体系结构：将功能分为一个控制层次，程序按层次调用

        IMG_20201220_233010

      2. 远程调用体系结构：将主 / 子程序的构件分布在多台计算机上

    4. 面向对象体系结构：构件中封装了数据和必须用于控制该数据的操作

    5. 层次体系结构：定义一系列不同的层次，每个层次各自完成操作，逐渐接近机器的指令集

    IMG_20201220_233012

    第十三章 构件级设计

    13.1 构件

    系统中模块化的、可部署的、可替换的构件，该部件封装了实现并对外提供一组接口

    13.1.1 面向对象观点

    构件包括一个协作类的集合，构件中的每个类都得到详细阐述，包括所有属性和与其实现相关的操作，并定义所有与其他设计类相互通信协作的接口

    IMG_20201220_232945

    13.1.2 传统观点

    一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及构件被调用和实现数据传递的接口构成

    IMG_20201220_232941

    13.2.1 构件的基本设计原则 SOLD

    这些原则的根本动机在于，使得产生设计在发生变更时能够适应变更并且减少副作用的传播

    • 开闭原则 / OCP：构件应该对外保持开放性，对修改具有封闭性。设计者应该采用一种无需对构件自身内部做修改即可进行拓展的方式来说明构件
    • 里氏替换原则 / LSP：子类可以替换他们的基类
    • 依赖倒置原则 / DIP：依赖于抽象而非具体实现，上层模块不依赖底层模块，而是依赖抽象
    • 接口分离原则 / ISP：多个用户专用接口笔一个通用接口要好

    构件打包原则：

    • 发布复用等价性原则：服用粒度就是发布粒度
    • 共同封装原则：一同变更的类应该合在一起
    • 共同复用原则：不能一起服用的类不能分到一组

    13.2.3 内聚性

    内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。

    • 功能内聚：通过操作实现，一个模块完成一组且只有一组操作并返回结果时
    • 分层内聚：通过包和构件和类来实现，高层能访问低层的服务，但低层无法访问高层的服务
    • 通信内聚：访问相同数据的所有操作被定义在一个类中

    13.2.4 耦合性

    耦合性是类之间彼此联系程度的一种定性度量。

    • 内容耦合
    • 控制耦合

    面向对象编程实际上要求面向接口编程

    1. 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
    2. 变量的表面类型尽量使接口或者抽象类。
    3. 不要覆盖基类中已实现的方法。

    第十四章 用户界面设计

    14.1 黄金规则

    1. 把控制权交给用户
    2. 减少用户的记忆负担
    3. 保持界面一致

    第十五章 质量概念

    15.2 软件质量

    在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值

    其强调了一下三个方面：

    1. 有效的软件过程：为生产高质量的产品奠定了基础，过程管理所做的是检验和平衡，防止项目混乱
    2. 有用的产品：指交付最终用户要求的内容、功能和特征，最重要的是以可靠、无误的方式交付
    3. 为软件的生产者和使用者增值：高质量软件为软件组织和最终用户群体带来收益

    15.3 软件质量困境

    要么错过了市场机会，要么几乎耗尽所有的资源。一方面，产品要足够好，不会立即被抛弃；另一方面，又不是那么完美，不需要花费太长时间和太多成本。

    “足够好的软件”

    ​ 提供用户期望的高质量功能和特性，同时也提供了其他更多包含已知的错误。

    15.3.2 质量的成本

    • 预防成本
    • 评估成本
    • 失效成本
      • 内部失效成本：软件发布之前发现错误
      • 外部失效成本：软件发布后发现的错误

    从预防道检查内部失效成本和外部失效成本，找到并修复的相关成本会急剧增加

    插图 P224

    第十七章 软件测试策略

    17.1.3 传统软件的测试步骤

    1. 单元测试
    2. 集成测试
    3. 确认测试
    4. 系统测试

    插图 P249

    测试人员参与项目的时机

    只有在软件体系结构完成后，独立的测试组才开始介入

    第十八章 项目管理

    22.1 管理的范围 4P

    1. 人员 People
    2. 产品 Product
    3. 过程 Process
    4. 项目 Project

    已知题目

    选择：

    1. 4.2.2 形式化方法模型

    判断：

    1. 有效的软件项目管理集中于4p，即人员，产品，过程和项目，他们的顺序不是 任意的

    材料分析题：

    1. P133safehome 设计与编码

    名词解释：

    1. UML：统一建模语言，一种标准的图形化建模语言。为软件开发的所有阶段提供模型化和可视化支持，具有简单，统一，图形化，能表达软件设计中的动态和静态信息

    2. QFD：质量功能部署，一种讲客户要求转化成软件技术需求的技术。目的是最大限度地让客户从软件工程中感到满意

    3. XP：极限编程 使用OOP方法作为推荐的开发规范，包含策划，设计，编码和测试4个框架活动的规则和实践

    4. 未知