软件工程做个复习

义贼 🐶

0x01软件工程概述

软件危机

软件的概念和特点：

• 软件是计算机系统中与硬件相互依存的另一部分，包括程序，数据及其相关的文档的完整集合。

• 软件是一个逻辑的而不是物理的产品；
  软件与硬件不同，软件是由开发或工程化而形成的，而不是传统意义上的制造产生的;
  软件不会“磨损”;
  大多数软件是自定义的，而不是通过已有构件组装的；
  软件本身是复杂的；
  软件成本相当昂贵。

“软件危机”术语首次出现：1968年NATO会议

软件危机的含义： 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。

• 如何开发软件，以满足对软件日益增长的需求；
• 如何维护数量不断膨胀的已有软件。

典型表现：

1. 对软件开发成本和进度的估计常常很不准确
2. 用户对“已完成的”软件系统不满意的现象经常发生
3. 软件产品的质量往往靠不住
4. 软件常常是不可维护的
5. 软件通常没有适当的文档资料
6. 软件成本在计算机系统总成本所占的比例逐年上升
7. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势

产生软件危机的原因：

1. 与软件本身的特点有关；
   (缺乏可见性；规模庞大）
2. 和软件开发与维护的方法不正确有关。

解决软件危机的途径：

了解产生软件危机的原因，澄清错误认识，建立起关于软件开发和维护的正确概念，还仅仅是解决软件危机的开始，全面解决软件危机需要一系列综合措施。包括： 技术措施（方法和工具）、组织管理措施、以及应用软件工程方法等。

---

软件过程模型

根据瀑布模型为下列任务排序:

软件过程：

为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

软件工程过程（Software engineering process）：

在软件工具的支持下，所进行的一系列软件工程活动。它的基本过程活动通常包括：

• P (Plan) : 规格说明。规定软件的功能及其运行的限制；
• D (Do) : 开发。产生满足规格说明的软件；
• C (Check) : 确认。确认软件能够完成客户提出的要求；
• A (Action) : 演化。为满足客户的变更要求，软件必须在使用的过程中演化。

软件过程模型：

(软件开发模型、软件生命期模型、软件工程范型)

软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。

---

掌握软件工程的相关知识点，包括软件工程原理和方法学。

掌握软件生命周期。

---

根据瀑布模型为下列任务排序：
验收测试、项目计划、单元测试、需求复审、成本估计、总体设计、设计复审、市场调研、详细设计、系统测试、实现、编制需求规格说明书。

答：市场调研→项目计划、成本估计、编制需求规格说明书（可以同时进行）→需求复审→总体设计→详细设计→设计复审→实现→单元测试→验收测试→系统测试。

瀑布模型

线性顺序模型

特点：

1)阶段间具有顺序性和依赖性。
2)推迟实现的观点。
3)质量保证观点。

规范的、文档驱动的方法；

但是最终交付的产品可能不是用户真正需要的

原型模型

快速成型模型

特点：
1)使用这种软件过程开发出的软件产品通常能满足用户的真实的需求；
2)软件产品的开发过程基本上是线性顺序过程。

螺旋模型

把它看作在每个阶段之前都增加了风险分析过程的快速原型模型

优点：

1）有利于已有软件的重用；
2）有助于把软件质量作为软件开发的一个重要目标；
3）减少了过多测试或测试不足所带来的风险；
4）软件维护只是模型的另一个周期，在维护与软件开发没有本质的区别。

风险驱动的螺旋模型适用于大规模的内部开发项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。

增量模型

递增模型、渐增模型

主要优点:

1)能在较短时间内向用户提交可完成部分的工作的产品；
2)逐步增加产品功能，从而使用户有较充裕的时间学习和适应新产品，减少一个全新的软件给客户带来的冲击。

---

0x02 可行性研究

可行性研究

前提：
假设问题定义已经清晰。并不是所有问题都有解法，因此对于无解（无解决的价值，或者在目前不能解决）的问题则不应该投入时间，人力和经费。
目标：
用最小的代价在尽可能短的时间内确定问题是否可解，或者确定问题是否值得去解。

• 技术可行性：
  使用现有的技术能实现这个系统吗？

  考虑的问题：
  1)开发风险
  2)资源有效性
  3)相关技术的发展

• 经济可行性：

  度量系统解决方案的性能价格比。

  考虑的问题
  1）成本/效益分析
  2）有形成本、效益
  3）无形成本、效益

• 操作可行性：

  1）用户使用可能性
  是否存在用户对新系统具有抵触情绪可能使操作不可行的情况。
  2）时间进度可行性
  估计项目完成所需的时间,评估项目的时间是否足够。
  3）组织管理的可行性
  确定系统是否能够真正解决问题。
  确定是否系统一旦安装后，有足够的人力资源来运行系统。

• 社会、法律可行性

数据流图 ⭐️

DFD,Data Flow Diagrams

数据流图的特性： 抽象性、概括性、层次性

优点：
1)总体概念强，每一层都明确强调“干什么”，“需要什么”，“给出什么”；
2)可以反映出数据的流向和处理过程。根据数据流向，定出存取方式，进一步作数据分析，向数据库设计过渡；
3)由于自顶向下分析，容易及早发现系统各部分的逻辑错误，也容易修正；
4)容易与计算机处理相对照。对应的处理过程可用相应的语言、判定表等工具来表达处理方法。
缺点：
1)不直观，一般都要在作业流程分析的基础上加以概括、抽象、修正来得到；
2)人工绘制太麻烦，工作量较大。

数据字典

---

0x03需求分析

需求分析

需求分析的结果：

通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明，它是分析阶段的最终成果。

任务： 准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 “需求规格说明书” 规范的形式准确地表达用户的需求。

需求分析和规格说明的艰巨性理由

需求获取面临的挑战（有题）：

1)问题空间理解
2)人与人之间的通信
3)需求的不断变化

从哪些方面验证软件需求

1. 一致性：任何一条需求不能和其他需求互相矛盾
2. 完整性：规格说明书应该包括用户需要的每一个功能或性能
3. 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的
4. 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题

---

掌握ER图和STD图的一些相关知识点。

---

0x04总体分析

掌握软件设计过程中应遵循的基本原理及相关概念

• 模块化是衡量软件设计好坏的一个重要准则

• 抽象

• 逐步求精

• 信息隐藏—>提高模块的独立性，减少修改或维护时的影响面。局部化有助于信息隐藏。

• 模块独立—>模块独立性取决于模块的内部和外部特征。模块的独立程度可以由两个定性标准来度量：模块之间的耦合性和模块自身的内聚性。其中耦合衡量不同模块彼此间互相依赖(连接)的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。

---

内聚和耦合⭐️

➡️ 强内聚、弱耦合

耦合性：

对一个软件结构内不同模块之间互连程度的度量。

耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。

• 非直接耦合：两个模块没有直接关系(模块1和模块2)，模块独立性最强。低耦合

• 数据耦合：一模块调用另一模块时，被调用模块的输入、输出都是简单的数据。属松散耦合

• 标记耦合：如两个模块通过传递数据结构(不是简单数据，而是记录、数组)加以联系，或都与一个数据结构有关系。

• 控制耦合：一模块通过开关量、标志、名字等控制信息，明显地控制另一模块的功能。

去除模块间控制耦合的方法：(1)将被调用模块内的判定上移到调用模块中进行;(2)被调用模块分解成若干单一功能模块。

• 外部耦合：一组模块均与同一外部环境关联(例如,I/O模块与特定的设备、格式和通信协议相关联),它们之间便存在外部耦合。外部耦合有时候是必不可少的,但这种模块数目应尽量少。
• 公共环境耦合(公共数据区耦合)：当两个或多个模块通过一个公共数据环境相互作用时，它们之间发生的耦合。
• 🙅内容耦合：是最高程度的耦合。一模块直接访问另一模块的内部信息(程序代码或数据)🙅

如何降低模块间耦合度：

(1) 如模块必须存在耦合，选择适当的耦合类型
原则：尽量使用数据耦合
　　　少用控制耦合和特征耦合
　　　限制公共耦合的范围
　　　坚决避免使用内容耦合

(2) 降低模块间接口的复杂性

内聚性：

内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。设计时应该力求做到高内聚。

类型：

---

掌握软件设计的启发规则

1 改进软件结构提高模块独立性
2 模块规模应该适中
3 深度、宽度、扇出和扇入都应适当

4 模块的作用域应该在控制域之内

• 模块的控制范围(控制域)：包括模块本身和其下属模块的集合。

• 模块的作用范围(作用域): 指受该模块内一个条件判定影响的所有模块的集合。

  修改方法：1.移入不受控的作用模块；2.上移判定点

5 力争降低模块接口的复杂程度
6 设计单入口单出口的模块
7 模块功能应该可以预测

掌握层次图、HIPO图以及面向数据流的设计方法(有题)

---

0x05详细设计

详细设计的结果基本上决定了最终的程序代码的质量。结构程序设计技术是详细设计的逻辑基础。

掌握结构程序设计的基本控制结构。

掌握人机界面的设计问题及设计指南的相关知识点。

---

过程设计的几个主要工具

程序流程图

基本控制结构：

PDL

过程设计语言、伪码

PDL语言具有下述特点：
1）PDL虽然不是程序设计语言，但是它与高级程序设计语言非常类似，只要对PDL描述稍加变换就可变成源程序代码。因此，它是详细设计阶段很受欢迎的表达工具。
2）用PDL写出的程序，既可以很抽象，又可以很具体。因此，容易实现自顶向下逐步求精的设计原则。
3）PDL描述同自然语言很接近，易于理解。
4）PDL描述可以直接作为注释插在源程序中，成为程序的内部文档。这对提高程序的可读性是非常有益的。
5）PDL描述与程序结构相似，因此自动产生程序比较容易。

---

盒图

N-S图

特点：

1、功能域明确，可以从盒图上一眼看出。
2、不可能任意转移控制。
3、很容易确定局部和全程数据的作用域。
4、很容易表现嵌套关系，也可以表示模块的层次结构。

表示方法：

---

PAD图

问题分析图

---

判定树

优点： 形式简单，易于掌握和使用。

举例：

---

掌握面向数据结构的设计方法。

掌握环形复杂度的计算方法。

程序复杂性主要指模块内程序的复杂性。

（有题）McCabe度量法，又称环路复杂性度量，是一种基于程序控制流的复杂性度量方法。

它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。

---

0x06实现

通常把编码和测试统称为实现。

编码风格⭐️

编码风格包括：源程序文档化，数据说明，语句结构、输入／输出方法和效率几个部分，力图从编码原则的角度提高程序的可读性，改善程序质量。

1.程序内部的文档

​ (1)恰当的标识符（变量和标号）的名字:精炼且意义明确的名字,缩写规则一致,给每个名字加上注解
​ (2)适当的注释：序言性注释和功能性注释
​ (3)程序的视觉组织：适当的利用空格、空行和移行能使程序的逻辑结构更加清晰

2.数据说明

(1)数据说明的次序应当规范化。
(2)当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。
(3)如果设计时使用了一个复杂的数据结构，则应注解说明用程序设计语言实现这个数据结构的方法和特点。

3.语句构造

每条语句应该简单而直接，不应为了片面追求效率而使代码变得过于复杂。

4.输入输出

（1）对所有输入数据都进行校验，以保证每个数据的有效性；
（2）检查重要的输入项组合的合法性；
（3）使得输入的步骤和操作尽可能简单，并保持简单的输入格式；
（4）输入一批数据时，使用输入结束指示符，不要要求用户说明输入项数；
（5）在以交互式输入／输出方式进行输入时，要指明可以使用的选择值或界限值；
（6）应允许缺省值；
（7）当程序设计语言对输入／输出格式有严格要求时，应保持输入格式与输入语句的要求一致；
（8）给所有的输出加注释，并设计输出报表格式。

5.效率

（1）效率是一个性能要求，因而应该在需求分析阶段确定代码效率方面的要求；
（2）通过好的设计可以提高效率；
（3）程序的效率和程序的简明程度是一致的，不应该为了提高代码效率而牺牲程序的清晰性和可读性。

---

软件测试基础

测试的目的是为了发现程序中的错误,是为了证明程序有错,而不是证明程序无错。

把证明程序无错当作测试目的不仅是不正确的, 完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的。

“测试的目的是说明程序正确地执行它应有的功能”也是错误的。

单元测试、集成测试和确认测试

通常软件测试至少分为单元测试、集成测试和验收测试3个基本阶段。

---

白盒测试和黑盒测试

黑盒测试:

(功能测试 、数据驱动测试、基于规格说明书的测试）

不深入代码细节，软件测试员充当客户来使用它。

白盒测试：
（开盒测试、结构测试、玻璃盒测试、基于覆盖的测试）

根据被测程序的逻辑结构设计测试用例，力求提高测试覆盖率。

了解软件的运作方式会影响测试手段。

区别：

黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序外部特征进行测试。

白盒测试是根据程序内部逻辑结构进行测试。

不论黑盒还是白盒测试都不能进行穷尽测试。

白盒测试方法中的逻辑覆盖⭐️

逻辑覆盖准则:
(1)语句覆盖：使程序中每个语句至少执行一次。

(2)判定覆盖：每个语句执行一次，且每个判定的真假分支都至少执行一次。

(3)条件覆盖：每个语句执行一次，且使每个判定的每个条件的可能取值至少执行一次。

条件覆盖不一定包含判定覆盖。

判定覆盖也不一定包含条件覆盖。

(4)判定/条件覆盖： 选取足够多的测试用例，使判断中的每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。

(5)条件组合覆盖：是更强的逻辑覆盖标准，要求所有可能的条件取值组合至少执行一次。

(6)点覆盖：测试路径至少经过程序图中每个节点一次。与语句覆盖标准相同。

(7)边覆盖：测试路径至少经过程序图中每条边一次。

(8)路径覆盖：程序中每条可能的路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）。但在路径数目很大时，做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。

黑盒测试方法中的等价划分和边界值分析

等价划分法：

把所有可能的输入数据(有效的和无效的)划分成若干个等价的子集 (称为等价类)，使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同。可从每个子集中选取一组数据来测试程序。

例1:某城市电话号码由三部分组成

地区码：空白或3位数字

前 缀：非‘0’或‘1’开头的三位数字

后 缀：4位数字

边界值分析设计测试用例原则:

1)如输入条件代表以a和b为边界的范围，测试用例应包含a、b、略小于a和略大于b的值。

2)如输入条件代表一组值，测试用例应当执行其中的最大值和最小值，还应测试略大于最大值和略小于最小值的值。

3)如规格说明中提出输入输出的有序集（顺序文件、有序表等)，则有序集的第一个和最后一个元素都要作为测试用例。

4)如程序数据结构有预定的边界，则应测试其边界的数据项。

5)如输出条件规定了取值范围，取边界上下浮动值做测试用例。

例1:邮件收费规定 1～5 kg收费2元

则应对: 0.9，1， 5，5.1 kg 或0.99，1， 5，5.01 kg设计测试用例。

例2:一个输入文件可有1～255个记录

则可分别设计有: 1个、255个、0个、256个记录的输入文件。

例3:程序中定义一数组，其元素下标的下界是0，上界是100

则应选择达到这个数组下标边界的值，如0与100作为测试用例。

例4：每日保险扣除额(输出项)在0～1165.25 元

则应设计测试用例使其恰好产生0元和1165.25元的结果,

此外还应考虑设计结果为负值或 >1165.25元的测试用例。(如: -0.01元和1165.26元)

---

0x07软件维护

软件维护

概念： 在软件产品发布后对软件产品进行的修改。

类型：

1）改正性维护3️⃣：为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程。

2）适应性维护2️⃣：在使用过程中，随着计算机 的飞速发展，外部环境（新的硬、软件配置）或 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。

3）完善性维护1️⃣：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。

4）预防性维护4️⃣：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

软件可维护性

概念： 软件可维护性是指软件维护人员理解、改正、改动或改进软件的难易程度。

提高软件可维护性是支配软件工程方法学所有步骤的关键目标。

主要影响因素：

1）可理解性

2）可测试性

3）可修改性

4）可移植性

5）可使用性

6）可靠性

7）效率

在各类维护中的侧重点 ：

	改正性维护	适应性维护	完善性维护
可理解性	√
可测试性	√
可修改性	√	√
可靠性	√
可移植性		√
可使用性		√	√
效率			√

软件文档

软件系统的文档（按内容）可分为用户文档和系统文档。

描述什么

用户文档：主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；

系统文档：描述系统分析、设计、实现和测试等各方面的内容。

要求

1、必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用；
2、必须描述怎样安装和管理这个系统；
3、必须描述系统需求和设计；
4、必须描述系统的实现和测试，以便使系统成为可维护的。

---

0x08面向对象方法学

面向对象方法学优点

基本概念

对象

定义1：对象是具有相同状态的一组操作的集合

定义2：对象是对问题域中某个东西的抽象，这种抽象反映了系统保存有关这个东西的信息或它交互的能力。也就是说，对象是对属性值和操作的封装。

定义3：对象::=<ID,MS,DS,MI>。ID标识名字，MS操作集合，DS数据结构，MI对外接口

类就是对具有相同数据和相同操作的一组相似对象的定义

封装 也就是信息隐藏，通过封装对外界隐藏了对象的实现细节。

条件：

(1) 有一个清晰的边界

(2)有确定的接口

(3)受保护的内部实现

继承是子类自动地共享基类中定义的数据和方法的机制。

面向对象分析建模的三个模型及关系

在面向对象分析中，主要由对象模型、动态模型和功能模型组成。对象模型是最基本、最重要、最核心的。

对象模型：

对象模型表示静态、结构化的系统的“数据”性质，是对模拟客观世界实体的对象以及对象彼此间关系的映射，描述了系统的静态结构。

通常，用UML提供的类图来建立对象模型。

动态模型：

一旦建立了对象模型之后，就需要考察对象的动态行为。

通常，可用UML提供的状态图来描述对象的状态、触发状态转换的事件以及对象的行为（对事件的响应）。

功能模型：

表示变化的系统的“功能”性质，指明了系统应该“做什么”。

通常，功能模型由一组数据流图组成。

关系：

复杂系统对象模型的五个层次

5个层次对应着建立对象模型的5项主要活动

• 主题层--------------------识别主题
• 类和对象层--------------找出类与对象
• 结构层--------------------识别结构
• 属性层--------------------定义属性
• 服务层---------------------定义服务

---

掌握面向对象设计模型的组成（系统设计和对象设计），及和软件复用的一些相关知识点。

掌握面向对象的主要测试方法

掌握几种典型的面向对象方法：Coad方法、Booch方法、OMT方法、Jacobson方法和UML。

紫色内容不是重点但是要自己看书