目录
第一章 | 软件工程概述
1.软件 = 程序 + 数据 + 文档
2.软件的特性：复杂性 | 一致性 | 可变性 | 不可见性
3.软件的特性使得软件开发过程变得难以控制，这是造成软件开发困难的根本原因
4.软件危机：在计算机软件的开发和维护过程中遇到的一系列严重问题
5.软件工程的定义：①在软件的开发、操作和维护中应用一种系统的、有纪律的、可量化的方法，也就是工程学在软件上的应用
6.软件工程的目的：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。
7.软件工程的基本要素：过程、方法、工具
8.软件开发的基本流程：获取需求 → 设计软件 → 实现软件的编写 → 确认与测试 → 上线与维护
9.软工七大基本原理：用分阶段的生命周期计划严格管理、按进行阶段评审、实行严格的产品控制、采用现代程序设计技术、结果应能清楚地审查、开发小组的人员应少而精、不断改进软件工程实践的必要性
10.好的软件：质量就是软件产品对于某个(或某些)人的价值
11.正确的软件：能满足用户需求，为用户创造价值；运行正确的软件：有或很少缺陷，且有很强的扩展性、性能、易用性
第二章 | 软件过程模型
1.软件工程过程：问题定义、需求开发、软件设计、软件构造、软件测试
2.软件过程的基本活动是：分析、设计、实现、测试、演化
3.软件开发的基本流程：获取需求 → 设计软件 → 实现软件的编写 → 确认与测试 → 上线与维护
4.软件开发是一个创造的过程，而不是制造的过程
5.敏捷宣言
【个体交互 胜过 过程和工具】人是获得成功的最为主要的因素
【可以工作的软件 胜过 面面俱到的文档】文档需适度
【客户合作 胜过 合同谈判】双赢比输赢好
【相应变化 胜过 遵循计划】为下两周做详细的计划，为下三个月做粗略的计划
6.敏捷开发方法是一组轻量级开发方法的总称，包含很多具体的开发过程和方法，最有影响的两个方法是极限编程（XP）和Scrum开发方法
7.模型的选择
【瀑布模型】①软件需求在开发初期即被完整地确定 ②用户使用的环境也很稳定
【原型化模型】适用于尽可能 快速建造出软件原型，以反应客户需求
【螺旋模型】适用于 大型软件 开发（经常变化、业务不确定）
【演化原型模型（迭代模型）】适用于所有 需求在开发初期不能很好地被理解，业务模型存在不确定性，系统易于维护和更改
【统一过程模型】现代大型信息技术项目
【敏捷开发】①团队庞大，沟通协作效率低，方便管理团队 ②希望高效地管理开发进度 ③产品复杂，不断有新的需求加入
*【可转换模型】对安全性和可靠性要求极高，需要在投入运行前进行验证。如ABS系统
第三章 | 软件需求
1.需求是对外可见的系统特征
2.需求管理的三大任务：需求获取、需求优选、攥写需求规格说明书（说明书描述了计算机系统的功能、性能及其约束）
3.需求的分类：【按产品/过程分类】产品需求（功能性、非功能性）、过程需求 【按抽象层次详细程度分类】业务需求、用户需求、系统需求、软件设计规约
4.需求过程：需求抽取、分析、规约、管理、验证
5.需求的来源：【干系人】（任何和系统有关的人） 【系统的应用领域】业务过程、组织规章制度 【现有系统文档资料】用户手册、数据样本、界面描述、报告样本、屏幕截图
第四章（上） | 面向对象
1.什么是软件对象：软件也是由不同类型的软件对象组成的．每个软件对象也有自己的状态和行为
2.对象不会接受任意的消息传递，对象可接受的消息通常被定义为该对象的一组方法
3.接口是一个软件对象所能提供的所有功能属性（服务）的集合。
4.设计一应该从客户对象的需求中“提取”服务对象类的接口以及各方法的具体实现，而不是向客户对象“推送”我们认为这个服务对象类应该提供的功能
5.早期OODの特点：不是基于OOA的，大多基于结构化分析结果、多数方法与编程语言有关
6.面向对象的设计OOD：在OOA模型基础上运用面向对象方法进行系统设计，产生一个符合具体实现条件的OOD模型。
7.几种典型的面向对象的方法，方法的异同体现于：概念、表示法、系统模型、开发过程、可用性、技术支持
8.UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言
9.SOLID原则：
单一职责原则（一个类有且只有一个职责）、
开闭原则（开放扩展性，封闭更改性）、
Liskov替换原则（子类中方法的前置条件不能强于父类中相应方法的前置条件。子类中方法的后置条件不能弱于父类中相应方法的后置条件）、
接口分离原则（在设计时采用多个和特定客户类(client)有关的接口要比采用一个通用的接口要好）、
依赖倒置原则（上层模块不应该依赖底层模块，它们都应该依赖于抽象；抽象不应该依赖于细节，细节依赖于抽象）
10.CRC卡片分拣法：
CRC卡片分拣法的作用是 根据用例描述中的名词确定类的候选者，根据用例描述中的名词确定类的候选者
由名词寻找实体类 由动词寻找职责也要从字面去发现职责 、根据边界类，控制类，实体类的划分来帮助发现系统中的类、对领域进行分析，或利用已有领域分析结果得到类、参考分析，设计模式来确定类
第四章（下）| UML建模
【类图】
1.类的分类：边界类（边界类位于系统与外界的交界处），控制类（控制其他类工作的类，其他类并不向控制类发送很多消息，而是由控制类发出很多消息），实体类
2.类图的构成：名字 | 属性 | 操作
3.类图的属性： [可见性 - + # ~]属性名 [:类型]
4.类图的操作：[可见性 - + # ~]操作名 [（参数列表）]
5.类的关系：关联关系 [普通箭头]、聚合关系（A中定义了B的类）[白色菱形箭头]、组合关系（A中定义了B的实例）[黑色菱形箭头]、泛化关系（继承）[白色三角箭头]、依赖关系（A使用到了B）[虚线普通箭头]、实现关系（子类指向父类）[虚线白色三角箭头]
6.关联类：关联类通过一条虚线连接至关联。
7.类图建模过程：定义类名 → 定义类属性 → 定义类的操作 → 建立类和类之间的关系 → 定义关联关系的多样性、方向和名字
【用例图】
1.用例图(use case diagram )：由参与者、用例以及它们之间的关系构成的,用于描述系统功能的动态视图。
2.用例建模的概要：概要描述、参与者Actor列表、用例Use-case列表
3.用例图的主要元素：参与者（与系统交互的人、与系统交互的外部系统、硬件设备）、用例（作为外部实体的参与者与系统的交互序列；即系统的一系列行为，为参与者提供有价值且可观测的结果。注意：用例不是功能分解的过程！）、关联、系统边界
4.用例关系：关联关系：表示参与者与用例之间的通信、泛化关系（电话订票、网络订票，都包含于”订票“）、包含关系（下订单 包含 提供用户信息）、扩展关系（”取消订单“ 是 ”检查订单状态“ 的扩展）。
5.包含关系 VS 扩展关系：前者一定会执行被包含的关系，但是后者的扩展用例可以执行也可以不执行
6.用例建模流程：画系统边界 → 列出actor-goal lists → 找到参与者 → 找到用例 → 按照时间流程和用例关系画出关系
【顺序图】
1.顺序图的作用：刻画系统实现某个功能的必要步骤
2.顺序图的元素：交互元素：对象，消息，生命线，激活期
3.对象分类：命名对象 Smith:Patient 匿名对象 :Patient 未知类的对象 Smith
4.建模过程：识别交互过程 → 识别参与者 放到最开始的未知 → 识别交互过程的对象 → 为每个对象设置生命线 → 依次画出交互信息
5.顺序图 VS 用例图：顺序图表达用例的单个场景实例的行为、顺序图表达对象间如何协作完成用例所描述的功能。
【状态图】
1.状态图用于表示【一个】类对象的全生命周期过程
2.有限状态机的主要元素：状态和转移、事件和行为
3.所有的对象 都有状态！！ 对象的存在 / 不存在 也是一种状态
4.描述状态图的图符元素有:状态图符、迁移图符、起始状态、终止状态、条件判定、发出信号、接收信号和并发等。
【起始、终止】必须要有起始和结束状态
【迁移】包含的元素：原状态、触发事件、动作表达式。若有多个迁移分支，则这几个分支间的条件应该是互斥的
【事件】变更事件、调用事件、时间事件、信号事件
【动作】在状态内部或者状态间迁移时执行的原子操作，两种特殊的动作：入口动作、出口动作
5.状态图建模过程：找出类 → 确定所有可能的状态 → 确定引起状态迁移的事件 → 确定迁移进行时对象执行的相应动作
第五章 | 软件体系结构
1.软件体系结构很重要，体系结构决定软件规模
2.SA的组成 = 构件 + 连接件 + 约束
3.SA的设计元素：处理元素、数据元素、交互元素
4.SA的内容：构件、连接、连接件、约束、质量、物理分布
5.SA的目标：可重用性、简单性、有效性、灵活性
6.软件体系结构风格：
管道过滤风格 优点：简单性、可扩展性、复用性、并发性、缺点：不适合用来设计交互式应用系统（交互性弱） 示例：媒体播放器
事件风格 事件系统是将应用看成是一个构件集合，每个构件直至发生对它有影响的事件时才有所动作。 示例：编译器
以数据为中心的风格（仓库体系结构）示例：基于数据库的系统结构
客户机/服务器结构 (Client/Server，CS)：
若 业务逻辑大多数和数据处理操作大部分在客户端，则称为 胖客户端
两层CS（胖客户端模型） 客户机 ←→ 数据库 Server处理数据的管理，Client实现应用逻辑和用户的交互
三层CS：三层体系结构 客户机 ←→ 应用服务器 ←→ 数据库
三层CS之BS结构：浏览器/服务器结构
三层CS之MVC结构：MVC每次请求必须经过"控制器->模型->视图"过程，才能看到最终展现的界面
三层CS之P2P结构：参与者既是资源提供者(Server)，又是资源获取者(Client)。
7.软件体系结构风格选择：
【层次化的思想】任何系统中
【顺序批处理风格 | 管道-过滤器风格】问题可分解为连续的几个阶段
【仓库 | 抽象数据类型(ADT) | OO风格】核心问题是应用程序中数据的理解、管理与表示
【仓库结构】如果数据是持久存在的
【主程序—子过程风格 | OO风格】任务之间的控制流可预先设定、无须配置
【事件系统 | C/S风格】任务需要高度的灵活性与可配置性、松散耦合性或者任务是被动性的
【虚拟机/解释器体系结构】设计了某种计算，但没有机器可以支持它运行
【基于规则的系统】实现一些经常发生变化的业务逻辑
8.软件体系结构 VS 设计模式 VS 框架
概念：
体系结构风格：用于描述某一特定应用领域中 系统组织的惯用模式 ,反映了领域中 众多系统所共有的结构和语义特性
设计模式：可解决一类软件问题并能重复使用的软件设计方案
软件框架：由开发人员定制的 应用系统的骨架，是整个或部分系统的 可重用设计
区别：
体系结构：呈现形式是一个设计规约，目的是指导软件系统的开发
设计模式：体系结构风格是广义上的设计模式。换句话而言，设计模式是体系结构的一个分支。
框架：是一个半成品的软件，目的是设计复用
第六章 | 编码规范
1.目的：提高编码质量，避免不必要的程序错误。增强程序代码的可读性、可重用性和可移植性
2.编码规范、注释规范、命名规范、语句规范
3.代码优化：以提高全局效率为主、局部效率为辅，先优化数据结构与算法、再优化执行代码，正确的代码要比速度快的代码重要，任何优化都不能破坏代码的正确性
4.优化总结：
性能优化的关键是如何发现问题，寻找解决问题的方法。
有效的测试是不可缺少的，通过测试找出真正的瓶颈，并分析优化结果。
避免不必要、不成熟的优化。不成熟的优化是错误的来源
第七章 | 软件测试
1.软件缺陷：失效、故障、错误、缺陷、过失异常
2.缺陷的演化：缺陷 → 故障 → 失效
3.软件测试的定义：验证软件正常工作、假定软件有缺陷
4.软件测试的目的：为了发现错误而执行程序的过程、找到迄今为止未发现的错误的测试用例、
5.软件测试的过程：计划 → 准备 → 执行 → 报告
6.软件测试的局限：不彻底、不完备、间接性
7.测试用例的要求：代表性、典型性，寻求系统设计和功能设计的弱点，有正确输入也有错误/异常输入，考虑用户的诸多场景
8.黑盒测试
等价类划分原则：子集互不相交，子集的并集为整个集合，只需从每一个等价类中选取一个输入作为测试用例，在输入条件规定了取值范围的情况下，可以确定一个有效等价类和两个无效等价类
无效等价类：
字符串：空字符串、长度超过的字符串、包含了不应该出现的字符
枚举：不符合要求的枚举元素
数组：空数组、不符合要求的数组元素
复合数据类型：对每个数据类型分别判断无效等价类，然后再进行排列组合
总测试用例数量 = 各部分的有效等价类个数之积 + 各部分的无效等价类个数
9.白盒测试
画出流程图 → 画程序流图
语句覆盖：代码中每个可执行语句至少被执行一次
判定覆盖：每个分支节点，必须都经过 Y、N各一次
条件覆盖：把所有分支节点可以取的值全列出来，然后设计测试用例，让每一个值都包含在测试用例中
判定条件覆盖：同时满足判定覆盖、条件覆盖
条件组合覆盖：把所有分支节点可以取的【组合】全列出来，然后设计测试用例，让所有的【取值组合】被覆盖
路径覆盖：选取足够多的测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）
计算环形复杂度（判断分支 + 1）或（E - N + 2）
1074
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
