软件工程笔记

一、软件

程序：
文档：开发、使用和维护程序所需的图形和文本信息
数据：是程序能够适当处理信息的数据结构

系统软件：为服务其他程序而编写的程序的集合。

• 用途：
  一部分处理复杂但确定的信息结构；
  一部分处理大量不确定的数据
• 特点：
  和计算机硬件大量交互
  多用户大量使用
  需要“调度、资源共享和复杂进程管理”的同步操作
  复杂的数据结构以及多种外部接口

应用软件：解决特定业务需求的独立程序

1. 工程/科学软件：广泛的“数字处理程序”。

• 从天文学到火山学，从汽车应力分析到轨道动力学，从计算机辅助设计到分子生物学，从遗传分析到气象学。

2. 嵌入式软件：驻留在产品或者系统中。

• 微波炉的键盘控制
• 汽车的仪表盘

3. 产品线软件：为不同的客户提供特定的功能

• 库存控制产品质量
• 文字处理电子表格软件
• 计算机图形
• 个人和企业的金融应用程序

4. Web/移动应用程序：WebApp。

• 其概念涵盖了广泛的应用产品。
• 最简单的可能是一组超文本链接文档，仅用文本和有限的图形表达信息。
• 随着Web 2.0的出现，Web应用程序正在演变成复杂的计算环境: 例如，在线游戏、在线社区应用程序。

5. 人工智能软件：利用非数值算法来解决不适合计算或直接分析的复杂问题。

• 该领域的应用包括机器人、专家系统、模式识别(图像和语音)、人工神经网络、定理证明和游戏。

老系统（Legacy Software）

---

三、软件过程结构（Software Process Structure）

软件过程：
程序的一种功能元素，它包含处理逻辑、实现处理逻辑所需的内部数据结构，以及允许调用组件和向其传递数据的接口。
(1)协调所有其他问题域组件调用的控制组件;
(2)实现客户所要求的全部或部分功能的问题域组件;
(3)负责支持A流程的功能的基础设施组件是执行或开发事物的顺序。
在开发产品或构建系统时，遵循一系列可预测的步骤(即路线图)非常重要，这有助于及时交付高质量的产品。
软件开发中遵循的路线图称为“软件过程”。

通用流程框架（Generic process framework/model）

• 沟通 Communication
• 规划 Planning
• 建模 Modeling
• 建设 Construction
• 部署 Deployment

四种 Process Flow

任务集（Task Set）
过程模式（Process Pattern）

四、过程模型 软件工程之过程模型

要注意产品和过程的二元性(duality)

4.1 规定性流程模型（Prescriptive Process Models）

• 在软件开发中追求结构和秩序
• 所有的软件过程模型都支持通用的框架活动，但是每个模型对框架活动的强调程度不同。
• 也被称为软件生命周期模型（Software life cycle model）

A. 瀑布模型（经典生命周期）

B. V - 模型

C. Incremental Process Models
演化过程模型（Evolutionary Process Models）
A. 原型模型（）

B. 螺旋模型（Sprial Model）

4.2 专业化流程模型（Specialized Process Models）

Tend to be applied when a specialized or narrowly defined software engineering approach is chosen.

4.2.1 基于组件开发（Component-Based Development）

结合了螺旋模型的优点，本质上是【Nie92】的进化版，需要迭代来创造软件。基于组件开发的模式包括由提前打包的软件零件而成的应用

优点：

• 重复使用软件，降低项目开发成本，减短开发周期。
• 建模和构建活动从识别候选组件开始。这些组件既可以设计为传统的软件模块，也可以设计为面向对象的类或类包。
• 不管用于创建组件的技术是什么，基于组件的开发模型包含以下步骤(使用进化方法实现)：
  1. 针对所讨论的应用领域，研究和评估可用的基于组件的产品。
  2. 考虑组件集成问题。
  3. 软件架构的设计是为了容纳组件。
  4. 组件已集成到架构中
     进行全面的测试以确保适当的功能。

4.2.2 The Formal Methods Model

Formal methematical specification of computer software.

优点：

• 歧义、缺失、不一致更容易被找到并改正
• 是在设计阶段的程序设计规范

缺点：

• 耗费时间
• 少数程序源具备该能力，需要广泛训练
• 对不太懂技术的人很难理解该模型

应用：

• 主要用于安全（飞机，医疗设计，经济）

4.3 统一过程（The Unified Process）（UP）

侧重于客户沟通，从用户视角描述系统
强调软件结构的重要性
用例驱动，以架构为中心，迭代和增量
认识到与客户沟通、从用户的角度描述系统以及保持描述一致性的重要性。

• 五种通用的框架活动，它们可以用于描述任意软件过程模型
  

4.4 个人和团队流程模型（Personal and Process Models）

五、敏捷开发（Agile Development）

一种响应客户快速变化的需求的软件开发方法。
它强调以人为中心的迭代方法来逐步开发软件。
Communication
Symplicity
Feedback
Courage
Respect(Humility)

重要性：

Individuals and interactions > processes and tools
working software > comprehensive documentation
Customer collaboration > contract negotiation
Reponding to change > follwing a plan

5.1 Agility

六、需求

6.1 需求工程（RE requirement engineering）

RE指持续理解需求的工作和技术；
从软件过程看，始于Communication，接着进行modeling。

6.1.1 功能需求 & 非功能需求
功能需求：描述系统需要的功能或服务
非功能需求：并不与特定功能直接关联（产品需求、制度需求、外部需求）

6.1.2 两类需求过程
（1）Waterfall Requirement
在项目早期完成需求分析
【Complete indentification of requirements early in the project】
（2）Evolutionary Requirement
与迭代开发结合，不断发现，记录，组织，跟踪变化的需求

6.1.3 七步需求分析
（1）Initiation
（2）Acquisition
（3）细化 Refinement

在初始和导出阶段获得的信息将在细化阶段进行扩展和细化。开发一个准确的需求模型以描述软件功能、特征和信息.

（4）协商 Negotiation
（5）说明书 specification
（6）评估 validation
（7）（需求）管理management.

6.2 建立基础

6.3 获取需求（Eliciting Requirements）
自所有利益相关者收集多角度观点，找出共同点并整合。

6.4 开发用例（Developing Use Cases）
【站在最终用户的视角】
（1）确定参与者

For example, the software that controls the computer requires 4 different interaction modes (roles): programming mode, test mode, monitoring mode, and fault-checking mode. Therefore, 4 participants can be defined as: programmer, tester, monitor and troubleshooter.

（2）Questions the use case should answer:

• Who are the primary and secondary participants?
• What are the goals of the participants?
• What preconditions are there before the story begins?
• What is the main job or function performed by the participant?
• What are the possible changes in the interactions of the participants?
• What system information will participants obtain, generate or change?
• Do participants have to notify the system about changes in the external environment?
• What information do participants want from the system?
• Do participants want to know that there will be unexpected changes?

（3）用例图

别人的：http://t.csdnimg.cn/wAxQ1

6.3.1 协作需求收集（Collaborative Requirements Gathering）
【会议】
人员：软件工程师和相关人员
规则：制定准备和参加会议的规则
时间：时间表，覆盖要点但允许自由交换观点
Bridgebuilder
Definition mechanism
【目标】
定义问题
提出方案
协商不同方法
确定方案集
【准备】【More explanation】

• 列出构成系统环境的对象
• 列出系统产出的对象
• 列出系统调用的对象
• 列出与对象交互的服务操作/服务（流程/功能）
• 列出开发约束（cost, size, business rules）与性能标准（speed，accuracy）

6.3.2 质量功能展开（Quality Function Deployment）

转换用户需求为技术需求的质量管理技术；
最大化客户满意度；
强调“What is valuable to cutomers”并贯穿工程；

三类需求：

正常需求：
期望需求：客户没说但是要
兴奋需求：客户没说，但是做了他们很高兴

6.3.3 使用场景【用例】

6.3.4 Elicitation Work Production

For most systems, the work products derived from requirements include:
Requirements and Feasibility Statement.
A description of the boundaries of the system or product range.
A list of customers, users, and other stakeholders involved in requirements export.
Description of the technical environment of the system.
A list of requirements (preferably organized by function) and the domain constraints to which each requirement applies.
A series of usage scenarios are helpful to gain an in-depth understanding of the usage of the system or product in different operating environments.
Any prototype that better defines requirements.
All those involved in requirements derivation need to review each of the above work products.

6.3.5 面向服务的方法（Service-Oriented Methods）

面向服务的开发将系统视为服务的集合。面向服务开发的需求获取关注于应用程序系统定义的服务。

6.6 避免一般错误

七、需求模型：基于场景

7.1 需求建模模型

描述客户需求并分析其正确性
为软件设计打下基础
定义一组在软件完成后可以验证的需求

【基于场景的模型】来自不同系统“参与者”观点的需求。

【数据模型】描述问题的信息域的模型。

【基于类的模型】表示面向对象的类(属性和操作)的模型，通过类的协作获得系统需求。

【基于流程的模型】 表示系统的功能元素并描述当功能元素在系统中运行时数据转换如何发生的模型。

【行为模型】显示软件如何响应外部事件或刺激。

分析经验法则：
关注可见需求，不要陷入细节；
需求模型的每一点都加深对软件需求的整体理解，并促进对信息域、功能和系统行为的理解；
基础结构和其它非功能模型应该推迟到设计阶段；
最小化整个系统的关联。类和函数之间的连接非常重要，但如果“互连”级别非常高，则应该找到减少互连的方法；
确保需求模型对涉众都有价值
简化模型

领域分析
目标：找出/创造广泛使用的分析类或者分析模式，使其可重复使用

7.2 基于场景的建模

八、需求建模：基于类 http://t.csdnimg.cn/u1NxW

---

九、需求建模：行为和模式 http://t.csdnimg.cn/Gvonj

---

十、需求建模：基于过程

10.1 数据流图（Data flow diagram, DFD）
数据流图
过程建模

外部实体：储户、日历
处理(数据变换)：检验、登录、付款
数据存储：帐卡、存折

10.2 状态转换图（State Transiton Diagram, STD）

---

十一、Component-Level Design http://t.csdnimg.cn/KBXYQ

组件（Component / module）：
程序的一种功能元素，它包含处理逻辑、实现处理逻辑所需的内部数据结构，以及允许调用组件和向其传递数据的接口。
(1)协调所有其他问题域组件调用的控制组件;
(2)实现客户所要求的全部或部分功能的问题域组件;
(3)负责支持问题领域所需处理的功能的基础设施组件。

12.1 针对构件的不同观点（视角）
传统系统结构图：

面向对象的结构图：

12.2 基于类的构件

四种基本设计原则：使得产生的设计在发生变更的时候能够适应变更并且减少副作用的传播

1. 开闭原则(The Open-Closed Principle,OCP): 构件应该对外延具有开放性，对修改具有封闭性，简单来说，设计者应该采用一种无需对构件自身内部的代码或者逻辑做修改就可以进行扩展，通俗一点说，就是当你想在家里放一些健身器材，与其在家里腾出空间来放，不如再建一层楼专门放器材。
2. Liskov替换原则(Liskov Substitution Principle , LSP): 子类可以替换它们的父类
3. 依赖倒置原则(Dependency Inversion Principle, DIP): 依赖于抽象，而不是具体实现，这就相当于你去市场买菜，如果每在一个摊位买菜就提一个塑料袋，那么到后面越提越多，再买菜就不好提了，我们就比较倾向于拉一个车车，把塑料袋都放在里面，这个车车就相当于我们对“购买的菜”的抽象
4. 接口分离原则(Interface Segregation Principle, ISP): 多个客户专用接口比一个通用接口要好，这个在生活中其实也很常见，如果我们在超市结账的时候，超市里面只有一个收银台，那么就势必会排长长的队，但是如果有多个收银台，那么结账速度就会提高
   

12.3 进行构件级设计

1. 标识出所有和问题域相关的设计类
2. 确定所有与基础设施相对应的设计类
3. 细化所有不需要作为复用构件的设计类
   在类或者构件协作的时候说明消息的具体细节
   为每个构件确定合适的接口
   细化属性，并且定义实现属性所需要的数据类型和数据结构
   详细描述每个操作中的处理流
4. 说明持久数据源(数据库&文件)并确定管理数据源所需要的类
5. 开发并且细化类或者构件的行为表示
6. 细化部署图来提供额外的实现细节
7. 考虑每个构件级设计表示，并且时刻考虑其他可选方案

12.4 WebApps的构件级设计

WebApp组件是
(1)一个定义良好的内聚函数，用于操作内容或为最终用户或用户提供计算或数据处理
(2)内容和功能的内聚包，为最终用户提供一些所需的功能。
因此，WebApps的组件级设计通常包含内容设计和功能设计的元素。

12.5 设计传统构件

图形化设计表示

表格式设计表示

12.6 基于构件的开发

Component Based Software Engineering (CBSE)

强调使用可重用的软件组件来设计和构建计算机系统的过程: 将重点从编码转移到组装软件系统; 重点是“集成”，而不是“实现”。

11.7 内聚（cohesion） & 耦合（coupling）

高内聚，低耦合
我们将内聚描述为组件的“专一性”。
内聚意味着组件或类只封装属性和操作。
功能内聚: 一个模块只执行一次计算，然后返回一个结果。(最佳衔接)目标:高衔接。

内聚&耦合：http://t.csdnimg.cn/R0Int

---

十二、软件测试策略

http://t.csdnimg.cn/9lY7T
http://t.csdnimg.cn/zQsax
http://t.csdnimg.cn/jaU4A

软件测试策略包括：测试计划、测试用例设计、测试执行、测试数据收集与评估
flexibility & strict

13.1 A Strategic Approach to Software Testing

1。进行有效的技术评审
2。测试从组件级别开始，并“向外”完成整个基于计算机的系统的集成。
3。不同的测试技术适用于不同的软件工程方法和不同的时间点。
4。测试是由软件开发人员和(对于大型项目)一个独立的测试小组进行的。
5。测试和调试是不同的活动，但是调试必须包含在任何测试策略中。

螺旋模型:

软件过程:沿着螺旋向内，经过设计阶段，最后到编码阶段，每一圈都会降低软件的抽象层次。
测试从组件层面开始，然后“扩展”到整个基于计算机的系统，每一轮测试都在扩大范围。

13.2 策略问题
软件测试策略只有在软件测试人员:
(1)早在测试开始前就以可量化的方式规定产品要求;
(2)明确规定检测目标;
(3)了解软件的用户，并为每个用户类别制定一个配置文件;
(4)制定强调“快速循环测试”的测试计划;
(5)构建能够自我测试的“健壮”软件
(6)在测试前使用有效的技术评审作为过滤器;
(7)进行技术评审，以评估测试策略和测试用例本身;
(8)制定检测过程的持续改进方法。

13.3 常规软件测试策略

Unit testing:
单元是被认为要被测试的最小模块。
主要评价模块的五个基本特征
(1)模块接口的测试是为了保证被测程序单元的信息能够正常进出。
(2)检查本地数据结构，确保临时存储的数据在整个算法执行过程中保持完整性。
(3)执行控制结构中的所有独立路径(基路径)，确保模块中的所有语句至少执行一次。
(4)对边界条件进行测试，确保即使达到边界值的极限或有限处理，模块也能正常运行。
(5)最后，测试所有错误处理路径。(try…catch)

Unit testing的特征：
注重最小单元的核查
关注组件内部处理逻辑和数据结构;
越早越好:测试驱动开发:先写测试代码，再开发;
模块接口测试的基础是:其他测试只有在数据正确进出模块时才有意义。

What is a test case?
A set of test inputs, execution conditions, and expected results compiled for a particular purpose in order to test whether a program path satisfies a specific requirement.

Unit testing Environment

13.4 确认测试【在集成测试的最后开始】

α 测试是由有代表性的最终用户执行的吗，开发者记录问题
β 测试一般无开发人员在场

13.5
集成测试的几种方法

1. One-step Integration

缺点：

1. All units are required to be ready, but in fact integration tests can be overlapped with unit tests in parallel, which is not conducive to development progress;
2. It is difficult to locate the problem. Once a problem occurs after integration, it is difficult to determine the specific cause and location of the error.
3. Suitable for smaller applications.
   

2. 集成测试（Incremental integration）：一步一步集成

增量测试的特点:
增量测试不需要所有的单元都准备好，并且并行地重叠单元测试和集成测试是可行的。
在测试期间，如果发现问题，通常可以将它们定位到新添加的单元中(定位问题更容易)。
适用于较大的应用。增量测试与非增量测试相比具有一定的优势。

Top-down：从主控制模块按照控制层次向下集成
1 .深度优先 or 广度优先？
2. 要写很多存根程序【其实就是函数，因为集成最开始只有主函数】
3. 主控模块的错误很早就会被发现

Bottom-up：
自下而上。

3. 回归测试：指对软件的新版本测试时，重复执行上一个版本测试时的用例。
4. 冒烟测试：对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。

冒烟测试的优点：
提高最终产品的质量。由于这种方法是面向构建(集成)的，吸烟方法有可能发现功能、体系结构和组件级的设计错误。如果早点纠正这些错误，产品的质量就会好一些。简化错误诊断和纠正。
与所有集成测试方法一样，在冒烟测试期间发现的错误可能与新的软件增量有关，也就是说，新发现的错误可能来自刚刚添加到构建中的软件。很容易评估进度。

13.6 面向对象软件的测试策略

一种是基于线程的测试，它集成了一组响应系统输入或事件所需的类。每个线程都是单独集成和测试的。应用回归测试以确保不会产生副作用。
另一种方法是基于使用的测试: 通过测试那些很少使用服务类的类(称为独立类)来开始构建系统 在测试独立类之后，使用独立类来测试下一级的类(称为依赖类) 继续测试依赖类，直到整个系统完成。

13.7 系统测试 & 调试
测试发现错误，调试修改不符合需求的表现

系统测试包括：
recovery test
Safety test
pressure test
Performance Testing
deployment test

13.8 软件测试基础
白球：正确输出
黑球：错误输出

13.9 基本路径测试（Basis Path Testing）基本路径测试

它以程序控制流程图为基础，分析控制结构的循环复杂度，推导出一组基本的可执行路径。
设计的测试用例必须确保程序的每个可执行语句在测试期间至少执行一次。

Flow diagram (or program diagram):
圆:流程图节点，表示一个或多个过程语句。
处理框序列和决策菱形可以映射为单个节点(与流程图相反)。
箭头:表示控制流的边或连接，边必须终止于一个节点，即使该节点不表示任何过程语句。

13.10 控制结构测试

循环复杂度(Cyclomatic complexity)：

软件工程中的一个定量度量，表示程序或函数的复杂性。它衡量程序源代码中线性独立路径或分支的数量。

黑盒测试：

挑边界值（特殊值）

13.11 基于模型的测试(Model-based Testing)

一种黑盒测试技术。在许多情况下，UML状态图(一种行为模型)被用作测试用例设计的基础。MBT技术需要以下5个步骤:

1. 分析软件的现有行为模型或创建一个行为模型。
2. 遍历行为模型并确定导致软件在状态之间转换的输入。输入将触发一个事件，导致转换发生。
3. 当软件在状态之间转换时，评估行为模型并注释预期的输出。回想一下，每个转换都是由一个事件触发的，并且作为转换的结果，调用某些方法并产生输出。对于步骤2中指定的每一组输入(用例)，指定期望的输出以在行为模型中描述它们。
4. 运行测试用例。测试可以手动执行，或者您可以创建测试脚本并使用测试工具执行测试。
5. 将实际结果与预期结果进行比较，并根据需要进行调整。

---

十五、测试面向对象的程序

15.1 拓展测试视野

(1)扩展测试的定义，将错误发现技术应用于面向对象的分析和设计模型;
(2)必须彻底改变单元测试和集成测试策略;
(3)测试用例设计必须考虑面向对象软件的独特性。

15.2 测试OOA & OOD模型

---

十六、管理软件项目

项目度量（PM, Project metrics）
个人软件过程（PSP, Personal Software Process ）

16.1 软件度量
【过程度量】
【项目度量】团队公有，合成过程度量
【产品度量】个人私有，合成项目度量

Thousand lines of code (KLOC)

软件的直接度量 & 间接度量

软件过程的直接度量包括花费的成本和工作。
产品的直接度量包括生成的代码行数、操作速度、存储容量，以及在一段时间内报告的缺陷。

产品的间接度量包括功能、质量、复杂性、可用性、可靠性、可维护性等。
eg. 面向功能的软件度量

生产力= KLOC/PM(人月)
质量=错误/KLOC
成本=元/LOC
文档=文档页数/ KLOC

16.2 面向功能的度量 http://t.csdnimg.cn/TxJH9

功能点（Function Point，FP）
功能点是根据软件信息域的特点和软件复杂性的评价来推导的；
主要考虑程序的“功能性”和“实用性”，而不是计算LOC。

功能点计算：

1. 用户输入数：面向应用的输入数据,包括对话框、屏幕信息、控件等；
2. 用户输出数：面向应用的输出信息，包括报告、屏幕信息、错误信息等；
3. 用户查询数：查询是一种联机的交互操作，每次询问/响应应计数：输入/输出的简单组合；
4. 文件数：每一个逻辑主文件都应计数；
5. 外部接口数：与系统中其他设备通过外部接口读写信息的计数

16.3 关键路径法（CPM）
详解关键路径法，这可能是你找得到最详细的了 - 简单项的文章 - 知乎
https://zhuanlan.zhihu.com/p/50905254

十七、E-R

https://zhuanlan.zhihu.com/p/270299029

十八、UML

http://t.csdnimg.cn/MuNTw