软件开发生命周期
软件开发生命周期（SDLC）是软件的产生直到报废的生命周期，具体有以下经典模型：
瀑布模型
该模型又称为“线性顺序模型”或者“传统生命周期”。原因，看上面的图：
- 它将整个过程分成了明确的阶段过程，而且顺序固定。
- 每个阶段都要有明确的输出，作为下一阶段的输入。如果下一阶段出现问题，就要返工，回到上一个阶段。
正是这种固定比较死板流程，用户没有反馈和修改需求的机会，所以必须要求开发项目需求是稳定的，开发人员很熟悉这次开发才可以，否则稍有变动，前面的开发就是无效的，前功尽弃的。
瀑布型还是很好理解的。
V型
它把整个开发过程分成了这些阶段：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。
但这些阶段不是线性的，而是左右绑定的对应关系。
比如，用户提出需求的时候，也要提出验收测试的标准，即验收测试需要通过哪些测试用例。
需求分析的时候，需要写出来整个系统测试所需的测试用例。
V模型强调了测试阶段的重要性（对测试进行分级，并和开发阶段相对应），但是仍然一开始需要固定需求，没有改变瀑布型的缺点。阶段仍然是串行，用户没有反馈的机会。
增量型
仍然没有解决上面两个类型的问题，只是将整个需求分成了几个版本。每个版本内部仍然是按照瀑布流方式进行工作的。
这样的好处是，是每个版本工作量变小了，任务变小了，人的信心就上来了。比如一开始就让你造航母，你肯定辞职不干了。但是把任务变小，让你先造个航母的底盘，你觉得还行。
演化型和喷泉型
这两种都是迭代型。我觉得根本没区别。演化型这个名词描述流程整体分类的，而喷泉型这个名词只是说每个版本内部的开发过程。 迭代型的核心是为了解决一开始需求不稳定的问题
演化型就是适用于一开始需求不是特别明确的。需求方太智障了。就说我要做个商城系统，但具体细节也不懂。所以程序员加班做了第一版。然后需求方看了，说不行啊，你这个商城没有广告怎么行，还有你这个商品下面没有相似推荐，商城主题也不能随着手机壳变化（大雾~），给我改。
于是程序员就做了第二版，后面还会有第三版，一直到最终版，最终版2，最终版3……
也就是说每个版本的需求一开始不是确定好的，而是用户看了上一个版本，进行反馈进而提出下一版本的需求，这是和增量型最大的区别。
喷泉型它讲的是迭代的过程中，前后两个版本的各个阶段是可以并行的。（这也是和增强型的第二个区别，增量型版本内部是瀑布型，而演化型的版本内部和版本之前是喷泉型）
比如在版本1中程序员开发过程和版本2中的需求提出这两个过程就可以同时进行，不需要是串行的。
螺旋型
可以理解螺旋型是迭代型的升级版。它的每个版本增加了风险分析。和迭代型的区别在于每个版本开发过程进行了修改和完善。
每个版本开发分成四个部分：
- 制定计划
- 风险分析
- 实施工程
- 客户评价
原型
总有说什么快速原型开发，然后吧啦吧啦一堆不是人话，我就不懂了，这也算软件生命周期的模型？？？
什么是软件生命周期模型？是定义软件开发过程的每一个步骤、方法。原型只是用来获取客户需求的一个方法一个工具，他根本就没有涉及到后续的开发方法
可以把原型这个工具和上面的迭代型或者螺旋型进行结合一起，每个版本开发前先做一个原型，让客户看一下，这样就不会出现驴同鸭讲的情况出现。
RUP
全称是Rational Unified Process。
译名是统一过程模型。
其实从这个名字上还是能理解那么一点点点的。
我们前面说的好几个模型，都是说一个项目分成好几个版本，然后每个版本分成好几个阶段。虽然喷泉型允许一定程度的并行，但还不是完全并行的。比如版本1的开发和版本2测试就不能同时进行，因为版本2测试依赖于版本1的开发。
也就是说，阶段之间还是有一定依赖性的，有一定的先后关系的。而且不同版本的开发内容也有所不同。
统一过程开发，将整个开发分成四个版本（初始、细化、构造、交付），而且每个版本的开发内容（阶段）完全一致，分为：
- 商业建模（Business Modeling）
- 需求（Requirements）
- 分析和设计（Analysis & Design）
- 实现（Implementation）
- 测试（Test）
- 部署（Deployment）
- 配置管理与变更管理（Configuration & Change Mgmt）
- 项目管理（Project Management）
- 环境（Environment）
这样每个阶段，我们可以理解为整个的项目工作的一个分类，因为它存在于每个版本中，持续在整个项目开发过程中，只是比重不同。
参考链接
软件工程 瀑布模型、原型模型、喷泉模型和V模型的优缺点及适用场景
什么是UML？
全称是Unified Modeling Language，译名是统一建模语言。
既然是一门语言，必定是有一定语法规则，以及这些规则表达一定的功能和意义的。
简单来说，UML就是一种图示规则，用来表达一些组件之间的关系。目前UML1.4定义了9种图示，每种图示对应一种表示的类别。
说到这儿，UML到底是什么？UML是一种图形语言，而非我们常见的类似java、c这种文本语言，它有下面三部分构成
UML构成
UML基本构造块
事物，你可以理解为图形符号/元素，有哪些图形符号，每个图形符号是什么含义
- 技术元素：接口(interface)、主动类(activeclass)、用例(usecase)、协作(collaboration)、构件(component)、节点(node)、类(class)、和对象(object)
- 行为元素：交互(Interaction)、状态机(Statemachine)
- 分组元素：包(Package)表示一些类的集合
- 注释元素：用来在UML模型上添加适当的解释部分。
- 事物之间关系，几个图形符号直接需要用线连接，虚线还是实线都是有规定的：关联、泛化、实现、依赖
- 图，图 = 事物+关系，图本身又可以作为一个整体，成为一个图形符号与另一个图进行连接
UML规则
一个图不可能只有图没有文字说明，UML图必须包括文字说明，即必须有UML规则
- 命名：每个图形符号，得有名字
- 范围：与类的作用域相似
- 可见性：Public，Protected，Private，Package
公共机制
换个名字就是公共规则，对每种图示都适用的规则
- 规格说明
- 修饰： UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上。例如：
+代表public、-代表private、#代表protect等。用斜体字表示抽象类。 - 扩展机制
UML图的分类
说完上面定义，具体说说UML9种图示的构造规则：
用例图
用来描述用户是如何使用一个系统的，是用户所能观察和使用到的系统功能的模型图。
组成元素
- 角色
- 用例(即系统的一个功能)
- 关系
类图
用来描述系统中的类以及各个类之间的关系
组成部分
第一层是类名，第二层是属性，第三层是方法。
这里需要特别说明，属性前面和方法名称前面可以添加修饰符号，表示不同的可见性。
[对象图]()
对象图描述的是一组对象之间的关系，而不是类之间的关系。它是类图的变体，但是又与之不同。表示在某一时刻这些类的具体实例和这些实例之间的具体连接关系。 （对象是类的实例化）
组成部分
对象的图示中在对象的名字下面要加下划线。对象名有下列三种表示格式：
- 对象名:类名
- :类名
- 对象名
活动图
本质上是一种流程图，它描述活动的序列，即系统从一个活动到另一个活动的控制流
作用是描述用例，描述类的操作
状态图
描述一个对象所处的可能状态以及状态之间的转移(状态是对象生命期的一个阶段，在该阶段中该对象要满足一些特定的条件，并可从事特定的活动。)
时序图
描述对象之间传送消息的时间顺序，是用来表示用例中的行为顺序
协作图
通过表示对象之间发送和接收消息，表示了一些对象之间的协作关系。
组件图(构件图)
用于描述系统中各个组件之间提供服务的关系。(构件是可以提供一些功能(接口)的实体，是物理上的概念)
部署图
描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。一个系统模型只有一个部署图，部署图通常用来帮助理解分布式系统。
模块独立性
这里涉及到三个概念：模块的独立性、内聚性和耦合性
模块独立性是通过模块间的耦合和模块的内聚这两个指标来体现的。
模块内部内聚程度越高，与其他模块的耦合程度相对越低。独立性越强。所以内聚和独立性正相关，耦合和独立性成负相关。模块的内聚是指模块内部多个功能块的聚合关系（相关性），耦合是模块之间的关系。
内聚
巧合内聚
集合函数巧合有一些代码是重复的，我们新建一个模块来承接这个重复代码。这个新的模块内部关系就是巧合内聚（ABC为不同的模块）
逻辑内聚
多个模块会调用一个共同的模块，这个公用模块包含若干个功能，根据传入的参数判断选用哪个功能。这个公用模块的内聚关系就是逻辑内聚
时间内聚
一个模块有多个功能，且所有功能在同一个时间段内全部执行，这个模块的内部关系就是时间内聚
过程内聚
一个流程图中的每个部分都可以作为一个过程内聚模块
通信内聚
一个模块的各个功能使用相同的输入或者产生相同的输出，则这个模块的内部关系叫通信内聚
功能内聚
一个模块实现一个总的功能，模块内部子功能都是完成这个总功能不可缺少的一部分
信息内聚
是多个功能内聚模块的组合。根据不同条件选择不同的功能。这些功能都是基于同一个数据结构。我个人认为，信息内聚是逻辑内聚的一个子集。
(从左到右内聚性不断变强)
耦合
非直接耦合
两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。
数据耦合
两个模块之间通过参数交换数据
标记耦合
两个模块之间通过参数传递标记信息(即一个数据结构的数据)
控制耦合
一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能
外部耦合
两个模块通过访问同一个全局外部简单变量（不是数据结构）产生的关系
公共耦合
两个模块都访问同一个公共数据环境(公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区)
内容耦合
一个模块直接访问另一个模块的内部数据
可以看出标记耦合和数据耦合很类似
外部耦合和公共耦合很类似
(从左到右耦合性不断变强)
软件测试
关于软件工程的黑盒测试和白盒测试
黑盒测试
- 等价类划分
- 边界值分析
- 错误推测法
- 因果图法
白盒测试
- 逻辑覆盖
- 基本路径测试
- 控制结构测试
(白盒测试都是和程序内部内容相关的，所以方法名称都离不开路径、结构、逻辑)
软件设计
模块的作用范围和控制范围
模块的控制范围 包括它本身及其所有的从属模块，这个是固定的，你直接从图中模块的从属关系就可以看出来。
模块的作用范围是指模块内一个判定的作用范围。这个判定是人性化的，是变化的。比如下图中，模块B2的作用域是什么呢？如果我们判定B2模块会影响A、B模块，那么他的作用域就是A和B，但是AB显然超出了B2的控制范围。
如果一个判定的作用范围包含在这个判定所在模块的控制范围之内，则这种结构是简单的，否则，它的结构是复杂的。
数据流图和数据词典
数据流图(4个部分)
- 数据流
- 加工
- 数据存储
- 外部实体
数据词典(5个部分)
数据流词条、数据元素词条、数据文件词条、加工词条、外部实体(5个部分)
