软件工程概述思维导图模板_ProcessOn思维导图、流程图

面向对象

封装、抽象

封装（Encapsulation）

信息隐藏和数据访问保护

抽象（Abstractin）

隐藏方法的具体实现，让调用者只需要关心方法提供了那些功能，并不需要知道这些功能是如何是实现的

不实现接口，也能满足抽象的特性，通过函数包括具体的实现逻辑，也是一种抽象

继承（Inheritance）

标识类之间的is-a的关系，比如猫（A）是一种哺乳动物（B）

多态（Polymorphism）

子类可以替换父类

重载、重写

提高扩展性、复用性

面向对象比面向过程的优势

面向对象

编程范式和编程风格

以类或对象作为组织的基本单元

将封装、抽象、继承、多态作为代码设计和实现的基石

支持类或对象的语法机制

面向过程

编程范式和编程风格

以过程（方法、函数、操作）为组织代码的基本单元

以数据（成员变量、属性）与方法相分离为最主要特点

流程化的编码风格，通过拼接一组顺序执行的方法来操作数据完成一项功能

缺点

不支持类和对象的概念

不支持丰富的面向对象变成特性（封装、继承、多态）

面向对象的优势

1.OOP更加能够应对大规模复杂程序的开发

2. OOP风格的代码更易复用、易扩展、易维护

3. OOP 语言更加人性化、更加高级、更加智能

系统设计原则

对扩展开放、修改关闭

定义

开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发

同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”

如何做到

最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态

里式替换（LSP）

定义

子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

违反原则

1. 子类违背父类声明要实现的功能

2. 子类违背父类对输入、输出、异常的约定

3. 子类违背父类注释中所罗列的任何特殊说明

接口分离原则

如果把“接口”理解为一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口等。如果部分接口只被部分调用者使用，我们就需要将这部分接口隔离出来，单独给这部分调用者使用，而不强迫其他调用者也依赖这部分不会被用到的接口。

控制反转、依赖反转、依赖注入

控制反转

“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行

依赖注入

将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用

依赖反转

依赖反转原则也叫作依赖倒置原则。程序要依赖于抽象接口，不依赖于具体实现。

测试与重构

重构

在保持功能不变的前提下，利用设计思想、原则、模式、编程规范等理论来优化代码，修改设计上的不足，提高代码质量。

重构是避免过度设计的有效手段

建立持续重构意识

单元测试

最可落地执行、最有效的保证重构不出错的手段就是单元测试（Unit Testing）

区别

集成测试的测试对象是整个系统或者某个功能模块，比如测试用户注册、登录功能是否正常，是一种端到端（end to end）的测试

单元测试的测试对象是类或者函数，用来测试一个类和函数是否都按照预期的逻辑执行。这是代码层级的测试。

好处

1. 单元测试能有效地帮你发现代码中的 bug

2. 写单元测试能帮你发现代码设计上的问题

3. 单元测试是对集成测试的有力补充

4. 写单元测试的过程本身就是代码重构的过程

5. 阅读单元测试能帮助你快速熟悉代码

计算机软件

什么是软件

程序：为实现设计的功能和性能要求而编写的 指令序列

数据：使指令能够正常操纵信息的数据结构

文档：与程序开发，维护和使用有关的图文资 料

软件的分类

按用途划分

系统软件

嵌入式软件

实时软件

人工智能软件

个人计算机软件

商业管理软件

工程科学计算软件

按规模划分

微型

小型

中型

极大型

软件危机

是指在软件开发和软件维护过 程中所存在的一系列严重问题

表现

软件开发无计划性，成本和工期经常失控

软件产品不能满足用户的实际需求

软件产品的质量无保证

软件的可复用性和可维护性较差

开发过程不规范，缺乏合格的文档资料

软件开发的人力成本持续上升

软件开发的生产率低下，满足不了急剧增长 的软件需求

原因

软件是逻辑产品，开发进度、成本难以估计 和控制

维护过程复杂，代价大

用户对软件需求的描述不准确，有遗漏，有 二义

忽视需求分析的重要性

文档不完备，不规范

过分强调编码技巧，忽视软件的可维护性

大型软件项目需多人协同完成，缺乏管理经 验

缺乏有力的方法学和支持工具

解决途径

推广使用成功的开发技术和方法

消除 错误的概念和做法

使用软件工具和软件工程支持环境

加强软件管理

软件生命周期

软件产品从策划、定义、开发、使用与维 护直到最后废弃所经过的一个漫长时期

阶段

三个阶段

软件定义

需求分析，项目策划，可行性研究

软件开发

对算法的设计，数据结构，体系架构的实现

运行和维护

软件应用，应用中的纠错和改进

软件工程

概念

Fritz Bauer

建立并使用完善的工程化原则， 以较经济的手段获得能在实际机器上有效 运行的可靠软件的一系列方法

IEEE

(1) 将系统化的、规范的、可度量的 方法应用于软件的开发、运行和维护的过 程；即将工程化方法应用于软件开发和维 护过程中；

(2) 对(1)中所述方法的研究

核心思想

采用工程的概念、原理、技术和方法来开 发和维护软件，把经过实践考验而证明是 正确的管理技术和当前能够得到的最好的 技术方法结合起来，从而大大提高软件开 发的成功率和生产率。

基本要素

方法

为软件开发提供了“如何 做某项工作的”的技术指南

工具

为软件工程方法提供了自 动的或半自动的软件支撑环境

过程

定义了如何把各种方法和 工具进行综合才能使软件开发合理，及时 的进行

基本原则

著名软件工程专家B.W.Boehm在1983年提 出了软件工程的七项基本原则

(1) 用分阶段的生命周期计划严格管理软件工程过 程

(2) 坚持在软件工程过程中进行阶段评审

(3) 实行严格的产品控制

(4) 采用现代的开发技术进行软件的设计与开发

(5) 工作结果应当是能够清楚地审查的

(6) 开发小组的人员应该“少而精”

(7) 承认不断改进软件工程实践的必要性