软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生成率、提高软件质量、降低软件成本。

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。

1.1 软件需求层次

软件的需求主要分为三个层次，从低到高依次是系统需求、用户需求和业务需求

1.1.1 系统需求

系统需求主要是从系统角度来说明软件需求，包括功能需求、非功能需求和设计约束

1.1.2 用户需求

用户需求指用户要求系统必须能完成的任务或功能

1.1.3 业务需求

业务需求是客户对相同高层次的目标要求，通过业务需求可以确定项目范围和视图，来自于项目投资人

1.2 需求分析与定义

1.2.1 质量功能部署

质量功能部署(Quality Function Deployment, QFD)是将用户要求转化成软件需求的技术，目的是最大限度的提升用户的满意度。QFD将软件需求分成三类，分别是常规需求、期望需求和意外需求

2.1 面向对象的基本概念

2.2 类之间的关系

类与类之间有不同的关系，主要有这六类：

UML(Unified Modeling Language) 是一种定义良好、易于表达、功能强大而且普遍使用的建模语言，它融入软件工程领域的新思想、新方法和新技术，作用域不限于支持面向对象分析（Object-Oriented Analysis，OOA）和面向对象设计（Object-Oriented Design，OOD）,支持从需求分析开始的软件开发全过程。

UML 独立于软件开发过程，它不是程序设计语言，是一种可视化的建模语言。

3.1 UML中的关系

UML 用关系把事物结合在一起，主要有以下四种关系（也就是类与类之间的6种关系）：

3.2 UML视图

UML 由视图(View)、图(Diagram)、模型元素(Model Element)和通用机制(General Mechanism)等几个部分组成：

而视图则是从不同视角为系统构架建模，形成系统的不同视图，主要有这样五类视图：

视图主要有图类组成，下面来看看具体的UML图

3.3 UML图

UML图总共有14种，如下所示：

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

4.1 软件架构风格

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomatic paradigm），核心问题是达到架构级的软件复用。Garlan 和Shaw对通用软件架构风格进行了以下分类：

4.1.1 数据流风格

数据流风格顾名思义，所有的数据是按照流的形式在执行过程中前进，不存在结构的反复与重构。主要包括批处理序列和管道-过滤器两种具体的架构风格。

4.1.2 调用/返回风格

调用返回就是指在系统中采用了调用和返回的机制。包括面向对象风格、主程序/子程序，层次结构三种：

4.1.3 独立构件风格

独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不通信，以降低耦合度，提升灵活度。主要包括进程通讯和事件系统子风格

4.1.4 虚拟机风格

人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样可以增加架构的灵活性。主要包括解释器和规则为中心的两种架构风格。

4.1.5 仓库风格

仓库风格中有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。仓库风格主要包括数据库系统、超文本系统和黑板风格。

4.2 软件设计

软件设计主要解决软件如何做的问题，合理的软件设计方案既可以保证系统的质量，也可以提高开发效率。从方法上来讲，软件设计分为结构化设计与面向对象设计。

4.2.1 结构化设计

结构化设计（Structure Design）是一种面向数据流的方法，是一个自顶向下、逐步求精和模块化的过程。其基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，主要分为概要设计和详细设计两个阶段

遵循原则：高内聚，低耦合

4.2.2 面向对象设计

主要任务是对类和对象进行设计，包括类的属性、方法，以及类与类之间的关系。通常遵循这六大原则：

详细可以看这篇文章：

4.2.3 设计模式

设计模式是前人经验的总结，它使得人们可以方便地复用成功的软件设计。详情可以看我的系列文章：

软件过程是软件生命周期中的一系列相关活动，即用于开发和维护软件及相关产品的一系列活动。软件产品的质量取决于软件过程。而在软件过程管理方面，最著名的是能力成熟度模型集成（Capability Maturity Model Integration, CMMI），它融合各种模型，形成了组织范围内过程改进的单一集成模型，其主要目的是消除不同模型之间的不一致和重复，降低基于模型进行改进的成本。

CMMI 主要有连续式和阶段式两种表示法结构：

5.1 连续式表示法

连续式表示法则是相对于单个CMMI过程域，使用能力等级来描述组织过程状态的特征。主要有过程管理、项目管理、工程和支持四个过程组。称为过程能力等级

5.2 阶段式表示法

阶段式表示法是相对于CMMI模型整体，使用成熟度级别来描述组织过程总体状态的特征。主要有初始级、可管理级、已定义级、量化管理级和优化管理级五个成熟度级别。称为组织成熟度等级

6.1 测试的方法

软件测试方法包括静态测试和动态测试。静态测试主要采用人工检测和计算机辅助静态分析的手段对程序进行检测；动态测试是指在计算机上实际运行程序进行软件测试。

6.1.1 静态测试

静态测试主要包括对文档和对代码的静态测试：

6.1.2 动态测试

动态测试主要包括白盒和黑盒测试：

其中静态测试的方法也可以实现白盒测试，属于白盒测试的范畴

6.2 测试的类型

测试可以分为单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等类别

6.2.1 单元测试

也叫做模块测试，测试的对象是可独立编译或汇编的程序模块。

6.2.2 集成测试

目的检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。

6.2.3 确认测试

用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度可以包括：

6.2.4 系统测试

系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。

6.2.5 配置项测试

配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与SRS的一致性。软件配置项测试就是开发已经完成，准备提供给客户的产品，可能是执行代码，也可能是产品文档。

6.2.6 回归测试

回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

综合来说，测试的顺序应该是单元测试->集成测试->配置项测试->系统测试->确认测试->回归测试

6.3 软件调试

软件测试的标志是发现错误，而软件调试则是根据错误迹象确定错误的原因和位置，并加以改正。

主要介绍软件层次的集成技术—企业应用集成（Enterprise Application Integration, EAI），企业应用集成技术可以消除信息孤岛，将多个企业信息系统连接起来，形成一个整体。EAI 主要包括表示集成、数据集成、控制集成和业务流程集成。

7.1 表示集成

表示集成也叫做界面集成，它是比较原始和最浅层次的继承。该方法把用户界面作为公共的集成点，把原有零散的系统界面集中在一个新的界面中。

同时表示集成也是黑盒集成，无须了解程序与数据库的内部构造。它是集成多个系统到一个集成点中。

7.2 数据集成

数据集成是白盒集成，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分布和共享。如分布式数据库提供连接的数据库访问中间件技术（数据中间件）

7.3 控制集成

控制集成也叫做功能集成或者应用集成，是在业务逻辑层上对应用系统进行集成。控制集成的集成点存于程序代码中，集成处可能只需要简单使用公开的API（应用程序编程接口）就可以访问。控制集成是黑盒集成。比如企业应用于微信公众号、小程序集成

7.4 业务流程集成

也叫做过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。它不仅要提供底层应用支撑系统之间的互联，同时要实现存在于企业内部的应用之间，本企业和其他合作伙伴之间的端到端的业务流程的管理。比如企业-银联-银行资金业务及流程集成。