2023spring 软工复习

Erikkoder

已于 2023-05-27 17:39:18 修改

阅读量143

点赞数 1

分类专栏：软件工程文章标签：软件工程学习

于 2023-05-26 21:05:22 首次发布

本文链接：https://blog.csdn.net/qq_52030860/article/details/130804029

版权

软件工程专栏收录该内容

1 篇文章 0 订阅

订阅专栏

第一章：基本软件过程活动

software specification

软件规格说明由软件开发人员给出，关于软件更改的决策由开发人员确定;

软件规格说明由软件的客户给出，他们对所需的软件变更做出决策。

软件规格说明或需求工程是理解和定义系统需要提供哪些服务，以及识别对于系统开发和运行的约束。

design & implementation

软件开发的实现阶段是把系统描述转换成一个可运行的系统的过程。

软件设计：设计符合描述的软件结构;

实现：将该结构转换为可执行程序;

设计和实现的活动是密切相关的，可以相互穿插的。

validation

软件确认，通常也称为验证和确认(V&V) ，目的是确定系统是否符合它的规格说明，以及系统是否符合客户的期望。

包括审查和评审过程和系统测试。

系统测试涉及使用测试用例执行系统，这些测试用例来自系统要处理的真实数据的规范。

测试是最常用的V & V活动。

evolution

软件本质上是灵活的，可以改变的。

当需求通过变更业务环境而变更时，支持业务的软件也必须进化和变更。

尽管在开发和进化(维护)之间有一个界限，但是随着越来越少的系统是全新的，这一点变得越来越无关紧要。

第2章：软件过程过程模型

瀑布模型（waterfall）

计划驱动的模型。描述和开发的不同阶段

瀑布模型中不同的阶段:

需求分析和定义
系统和软件设计
实现和单元测试
集成和系统测试
运行和维护

瀑布模型的主要缺点

1.是在过程开始后很难适应变化。原则上，一个阶段在进入下一个阶段之前必须完成。

2.不能灵活划分为不同的阶段，难以应对不断变化的客户需求。

只有在全面理解了需求，而且在系统开发过程中不太可能发生重大改变的时候，可以采用瀑布模型。

很少有业务系统具有稳定的需求。

3.瀑布模型主要用于大型系统工程项目，其中一个系统是在几个地点开发的。

在这些情况下，瀑布模型的计划驱动性质有助于协调工作。

增量式开发(incremental development)

描述、开发和验证交错进行。可以是计划驱动的，也可以是敏捷的。

增量式开发的思想是先开发出一个初始的实现，然后从客户那里获取反馈并经过多个版本的演化直至得到所需要的系统。

adj：

1.降低了适应用户需求变更的成本。

重新分析和修改文档的工作量较之瀑布模型要少很多。

2.在开发过程中更容易得到用户对于己做的开发工作的反馈意见。

用户可以评价软件的现实版本，并可以看到已经实现了多少。

3.使更快地交付和部署有用的软件到客户方变成了可能

相比于瀑布模型，用户可以更早地使用软件并创造商业价值。

pb：

1.过程不可见。

管理者需要常规的交付物来掌握进度，如果系统是快速开发的，那么要产生反映系统每个版本的文档就很不划算。

2.伴随着新的增量的添加，系统结构会逐渐退化。

除非投入时间和金钱用在重构系统结构上以改善软件，否则定期的变更会损坏系统的结构。随着时间的推移，越往后变更系统越困难．而且成本也将逐渐上升。

集成和配置(integration & configuration)

...

原型(prototype)

原型是一个软件系统的早期版本，用于演示概念、尝试候选设计方案、发现更多的问题和可能的解决方案。

软件原型可以用在：

在需求工程过程中，原型有助于启发和验证系统需求。

在系统设计过桯中，原型可用于探索特定软件的解决方案，并支持用户接口设计。

在测试过程中，进行回归测试。

adj：

提高系统可用性
更贴近用户的实际需求
改善设计质量
提高可维护性
减少开发工作

原型开发

可能是基于快速原型语言或工具

可能涉及遗漏功能

关注于那些不是理解很清楚的区域
错误检测和系统恢复一般不包括在原型中
关注功能性需求，而不是非功能性需求，比如可靠性和安全性；

增量式交付(incremental delivery)

不是将系统作为单个整体交付，而是将开发和交付分解为增量，每个增量交付所需功能的一部分。用户需求被划分优先级，最高优先级的需求包含在早期增量中。一旦开始了增量的开发，需求就会被冻结，尽管后续增量的需求可以继续发展。

增量式交付

部署供最终用户使用的增量;
更现实的评估软件的实际使用;
难以实现替换系统，因为增量的功能比被替换的系统少。

adj：

客户不用等到整个系统交付就能从系统中获得价值。
客户可以将早期的增量作为原型，从中获得对后续系统增量的需求的经验。
降低项目整体失败的风险。
具有最高优先权的服务接受了最多的测试。

pb：

1.当新系统准备替换一个已有的系统时，迭代化交付会有问题。

用户需要旧系统的所有功能，通常不愿意用一个不完整的新系统进行测试。

2.大多数系统需要一组由系统不同部分所使用的基本设施。

增量实现之前相关的需求并没有详细定义，所以很难确定所有增量都需要的公用基础设施。

3.迭代过程的本质是软件规格说明和软件一起开发的。

然而，这与许多机构的采购方式相冲突，因为完整的系统规格说明往往作为系统开发合约的一部分。

第4章：功能性需求和非功能性需求

功能需求

包括对系统应该提供的服务、如何对特殊输入做出反应，以及系统在特定条件下的行为的描述。
功能需求可能还需明确声明系统不应该做什么。
- 功能需求描述系统所提供的功能或服务。
- 它取决于开发的软件类型、软件潜在的用户，使用软件的系统的类型。
- 功能性用户需求可能是系统应该做什么的高级声明。
- 功能性系统需求则需要详细地描述系统服务。

eg：

用户能够搜索到所有诊所的预约挂号单。
系统每天能够为每个诊所生成一份想预约在那天就诊的病人名单。
每位使用该系统的职员都可以通过他的8位雇员号码被唯一地识别。

非功能需求

对系统提供的服务或功能给出的约束。包括时间约束、开发过程的约束和所受到的标准的约束。
经常适用于整个系统而不是个别的系统功能或服务。
- 定义了系统属性和约束，例如可靠性、响应时间和存储需求。约束包括I/O设备能力、系统表示等。
  
  也可以指定过程需求，要求使用特定的IDE、编程语言或开发方法。
  
  非功能性需求通常会比个别的功能性需求更加关键。如果一个非功能系统需求没有满足则可能使整个系统无法使用。

类型：

需求描述

格式化描述，包括前置条件，后置条件，触发条件，正常流程等。

第5章：

用例模型（use case）

序列图（sequence diagram 顺序图）

类图

状态图（state machine）

活动图（activity diagram ）

活动图相对于状态图，活动在框内

ER图

第6章：

体系结构模型

体系结构设计

这是系统设计过程的早期阶段.

是软件描述（需求工程过程）和设计过程之间的桥梁。

通常与一些规范活动并行执行。

包括识别主要的系统组件以及组件之间的通信和交互。

4+1视图

逻辑视图，它显示了系统中对象和对象类的一些主要抽象。

进程视图，显示在运行时系统是如何组织为一组交互进程

开发视图，它显示了软件是如何为了开发而被分解的。

物理视图，它显示了系统硬件和系统中软件组件是如何分布在处理器上的。

体系结构模式：

名字	MVC (模型-视图－控制器)
描述	将表示和交互从系统数据中分离出来。系统被设计成由3个彼此交互的逻辑组件组成：模型组件管理系统数锯和在数据上的操作，视图组件定义和管理如何显示数据给用户，控制器组件管理用户的交互（例如，键按下，鼠标点击等），并传递这些交互给视图和模型。参见图6.3
实例	图,6.4说明了采用MVC模式的基于Web的应用系统的体系结构
使用时机	在数据有多个显示和交互式的时候使用。也可在对未来数据的交互和表示需求不明确的时候使用
优点	允许数据独立地改交，不影响表示，反之亦然。支待对相同数据的多种不同方式的表达，对某种表示的变更会传递到所其他的表示
缺点	可能需要额外的代码，当数据模型和交互很简单时，代码的复杂度相对较高

MVC模式组成

仓库模型（repository）/容器模式

名称	容器
描述	系统的所有数据在一个中央容器中管理，该中央容器可以被所有系统组件访问。组件间不是直接进行交互，它们只通过容器进行交互
实例	图6-9是IDE的一个实例，组件使用一个系统设计信息的容器。每个软件工具生成信息放入容器，然后被其他工具所使用
使用时机	当一个系统中所生成的大量信息需要持久保存时，可以使用该模式。也可以在数据驱动系统中使用该模式，每当容器中收入数据时将触发一个动作或工具
优点	组件是独立的，它们无需知道其他组件的存在。一个组件的变更可以传播到所有的组件。所有的数据可以得到一致的管理（例如，在同一时间进行备份），因为它们是存放在同一个地方
缺点	容器是一个单个失败点，因而容器中的问题会影响整个系统。在组织所有通过容器进行的通信时会比较低效。将容器分布到多个计算几上会很困扰

层模型（layer）

用于建模子系统的接口。

将系统组织成一系列的层次，每一层提供一组服务。

支持不同层之间子系统的增量开发。当一层的接口发生变化时只影响相邻的层。

然而，通常需要认为将系统组织成这种方式。

名字	分层体系结构
描述	将系统组织成分层结构，每一层中包含一组相关的功能．每一层提供服务给紧邻的上一层，因此最底层是有可能被整个系统所使用的核心服务。参见图6-6
实例	存在于不同的图书馆中的共享版权文档的系统分层模型，参见图6-7
使用时机	在已有系统的基础上构建新的设地时使用；当开发团队由多个分散的小团队组成，且每个小团队负责一层的功能时使用；或者是当系统存在多层信息安全性需求时使用
优点	允许在接口保持不变的条件下更换整个一层。在每一层中可以提供冗余服务（例如身份验证）以增加系统的可靠性
缺点	在具体实践中，在各层之间提供一个干净的分离通常是困难的，高层可能不得不直接与低层进行直接交互而不是间接通过紧邻的下一层进行交互。性能可能是个问题，因为服务请求会在每一层中被处理，所以会需要多层解释

client/server

是一个分布式系统模型，数据和数据的处理由一系列分布的组件处理。

可以在一台计算机上实现。

一组能提供独立服务的服务器，如打印，数据管理等服务。

一组向这些服务请求的客户。

一个连接这些客户和服务的网络。

名称	客户机-服务器
描述	在客户机－服务器体系结构中，系统的功能是以服务的形态存在的，每一个服务来自于某个单独的服务器。客户机是那些使用服务和访问服务器的用户
实例	图6-11是一个电影和视频/DVD资料库．示例是以客户机－服务器形式存在的系统
使用时机	当需要从很多地点访问共享数据时使用。因为服务器可以复制，所以也可以在系统负载经常变化时使用
优点	该模型的主要优点是服务器可以分布到网络上。一般性的功能（例如打印服务）可以被所有的客户机使用，但并不需要被所有的服务所实现
缺点	每个服务是单个失败点，所以对阻止拒绝服务攻击或服务过失败缺乏免疫性．性能也可能是无法预知的，因为它依赖于网络也依赖于系统。当服务器属于不同的机构时，也存在管理方面的问题

第7章

类的识别和设计

识别对象类通常是面向对象设计的一个困难部分。

没有用于对象识别的“神奇公式”。它依赖于系统设计者的技能、经验和领域知识。

对象识别是一个迭代过程。你不太可能第一次就对。

设计模型参照第5章内容

上下文模型

上下文模型用于界定系统上下的边界-显示系统边界之外的内容。

社会和机构等非技术性因素可能影响系统的边界定义。

体系结构模型用于描述系统和相关系统之间的联系。
交互模型

为用户交互建模有助于识别用户需求

为系统与系统之间的交互建模可以突出可能出现的通信问题

为系统各部分之间的交互建模有助于分析所提出系统结构能否实现系统所需的功能及其可靠性。

用例图和顺序图用来建立交互模型

结构模型

软件的结构模型表示的是系统的构成，表示为组件构成系统以及组件之间的关系

有的结构模型是静态模型，表示系统设计的结构；有的是动态模型，表示系统执行时的构成。

我们建立结构模型以讨论和设计系统体系结构。

对象类聚合模型

聚合模型显示了聚合类是如何由其他类组成的。

聚合模型类似于语义数据模型中的局部-整体关系。

行为模型

行为模型是描述系统运行时的动态行为的模型，表示当系统响应来自所处环境的刺激时所发生的或有可能发生的事情。

这样的刺激有两种：
- 数据一些数据到达必须由系统处理。
- 事件某些触发系统处理的事件发生。事件可能会有相关联的数据，但并不总是这样。
数据驱动模型

许多业务系统是主要由数据驱动的数据处理系统，它们由输人数据所控制，很少处理外部事件。

数据驱动模型描述一个动作序列，该动作序列涉及输人数据的处理和相关输出的产生。

数据驱动模型非常有用，因此它们可用来表示系统中端到端的过程。
事件驱动模型

实时系统通常是事件驱动的，数据处理很少。例如，固定电话交换系统通过产事件驱动模型表示系统对内外部事件的响应方式。

这种模型建立在以一个假设为基础的，即系统状态是有限的，并且事件（激励）可能引起从一种状态向另一种状态的转变。
状态机模型

这些模型对于来自系统外部和内部的事情的系统响应行为进行建模。

它们表示系统对激励的反应，因此经常用于实时系统建模。

状态机模型将系统状态表示为一个节点，而把事情表示为连接这些节点的弧线。当一个事件发生时，系统从一个状态移动到另一个状态。

状态图是UML不可分割的一部分，用于表示状态机模型。

第8章

软件测试活动

测试用例（test case）

测试数据是为了测试系统而设计的输入。

测试用例是一个对输入和在特定环境下的期望的输出以及所测试的对象的一个描述。

黑盒测试

一种将程序视为“黑盒”的测试方法

程序测试用例基于系统描述

白盒测试/结构测试

根据程序结构派生测试用例。
程序的知识用于识别附加的测试用例
目标是练习所有的程序语句(不是所有的路径组合)

一般的测试原则

选择能够迫使系统产生所有错误信息的输入

设计能够使系统的输入缓冲溢出的输入

重复相同的输入或一系列输入很多次

迫使产生无效的输出

迫使输出结果太大或太小

等价类划分（equivalent partition）

程序的输入数据和输出结果总是落在几个不同且具有共同特征的类中。

程序通常对一个类中的所有成员其行为都是差不多的。由于这些等价的行为，这些类通常叫做等价划分或是域。

所设计的测试案例要使得输入和输出落在这些划分中。

路径测试（path test）

路径测试的目标是确保测试用例集使得通过程序的每个路径至少执行一次

路径测试的起点是一个程序流图，其中显示了代表程序决策的节点和代表控制流的弧

因此，带有条件的语句是流图中的节点

接口测试

目标是检测接口错误或无效的接口假设引起的故障

接口类型

参数接口在这些接口中，主要是数据和函数指针，由一个组件传递到另一个组件。
共享内存接口在这些接口中，有一个被子系统共享的内存块。
程序接口在这些接口中，有子系统封装的一组程序，这些程序可以被其他子系统调用。
消息传递接口在这些接口中，子系统通过消息传递来请求其他子系统上的服务。

基于需求的测试

基于需求的测试包括检查每个需求并为其开发一个或多个测试。

MHC-PMS 需求:

如果知道一个病人对任何特殊药物过敏，那么有该药物的处方将导致向系统用户发出警告消息。

如果开处方的医生选择忽略过敏警告，那么他/她应当提供一个忽略的原因。

确认测试

第22章：

风险管理

def：

风险管理是指识别风险并制定计划，使风险对项目的影响最小化。

可以把风险看做是一些可能实际发生的不利因素

项目风险是影响项目进度或项目资源的风险。

产品风险是影响开发中软件的质量或性能的风险。
业务风险是影响软件开发机构或软件产品购买机构的风险。

常见实例

风险	风险类型	描述
职员跳槽	项目	有经验的职员将会未完成项目就跳槽
管理层变更	项目	管理层结构将会发生交化，不同的管理层考虑、关注的事情会不同
硬件缺乏	项目	项目所需的基础硬件没有按时交付
需求变更	项目和产品	软件需求与预期的相比，将会有许多变化
描述延迟	项目和产品	有关主要的接口的描述未按期完成
低估了系统模型	项目和产品	过低估计了系统的规模
CASE工具性能较差	产品	支持项目的CASE工具达不到要求
技术变更	业务	系统的基础技术被新技术取代
产品竞争	业务	系统还未完成，其他有竟争力的产品就已经上市了

过程

风险识别

§识别可能的项目风险、产品风险和业务风险。

风险分析

§评估这些风险出现的可能性及其后果。

风险规划

§制定计划说明如何规避风险或最小化风险对项目的影响。

风险监控

§对整个项目的风险进行监控。

第23章： cocomo2模型

基于项目经验的经验模型。

良好的记录，这是不依赖于特定的软件供应商的“独立”模式。

历史悠久，从1981年出版（COCOMO-81）的初始版本，到开发中考虑更多现代方法（如使用动态语言的快速开发、组件组合开发，以及数据库编程）COCOMO 2模型。

COCOMO2模型考虑到不同的软件开发方法、复用等等。

COCOMO 2采用了一系列的子模型进行越来越详细的软件估计。

COCOMO2中的子模型：

应用组合模型。对所需的工作量建模，基于应用点对软件规模进行估算。
早期设计模型。需求已有，但设计尚未开始时使用。
复用模型。用于计算集成可重用组件的工作量
后体系结构模型。在系统架构已设计和取得有关系统的更多信息后使用。

COCOMO 估计模型

应用组合模型

支持原型设计项目和有广泛重用的项目。

根据开发人员标准的应用程序（对象）点/月的生产率来估算。

采用CASE工具的也考虑在内。

计算公式为

PM = ( NAP × (1 - %reuse/100 ) ) / PROD

PM是以人月为单位的工作量，NAP是交付系统的应用程序点的总数， PROD是应用点生产率。

早期设计模型

需求已得到同意后，估算才进行。

基于算法模型的标准计算公式

PM = A SizeB × M where

M = PERS × RCPX × RUSE × PDIF × PREX × FCIL × SCED;

A = 2.94是初始校准；工作量是KLOC，B变化从1.1到1.24关乎项目的创新程度、开发的灵活性，采用的风险管理方法和过程的成熟度。

复用模型

考虑不需要改变的黑盒代码和必须与新的代码集成的代码。

有两个版本：

黑盒复用，其中的代码不会被修改。工作量估计（PM）计算。

白盒复用，其中的代码修改。按相当于新的源代码行数大小估计来计算。然后调整大小估计为新代码。

后体系结构层

使用与‘早期设计模型’相同的公式，但有17个而不是7个相关的乘数。

代码的大小估计为以下3项的和：

新的待开发代码行的数量

基于用复用模型计算得到的等价代码行数的复用成本的估计；

由于需求变更可能要修改的代码行数的估计。

*其它：课后习题

开发模型

防抱死制动系统这是⼀个安全关键系统，因此在实施前需要进⾏⼤量的前期分析。它当然需要⼀种计划驱动的开发⽅法，并仔细分析需求。因此，瀑布模型是最合适的使⽤⽅法，也许是在不同开发阶段之间进⾏正式转换。

虚拟现实系统这是⼀个需求将发⽣变化的系统，并且将有⼀个⼴泛的⽤户界⾯组件。或许，⼀些UI原型设计的增量开发是最合适的模型。可以使⽤敏捷过程。

⼤学会计系统这是⼀个系统，其要求相当⼴为⼈知，并将与许多其他系统（如研究补助⾦管理系统）结合使⽤。因此，基于᯿⽤的⽅法可能适合于此。

交互式旅⾏计划系统具有复杂⽤户界⾯但必须稳定可靠的系统。增量开发⽅法是最合适的，因为系统需求将随着系统的真实⽤户体验⽽变化

活动图和状态图

目的不同：活动图主要用于描述业务流程或系统操作的流程，强调活动和行为；状态图主要用于描述对象或系统在不同状态之间的转换和行为。
重点不同：活动图关注流程中的动作和行为，而不是状态；状态图关注状态之间的转换和行为。
表示方式不同：活动图通常用箭头和节点表达不同步骤的顺序关系，可以展示同步、分支、合并等行为；状态图通常使用圆形、矩形和箭头来表示状态、事件和迁移。
应用场景不同：活动图通常用于分析和设计业务流程或系统操作；而状态图通常用于系统建模和软件开发过程中，以帮助程序员更好地理解和实现系统行为。

写一个测试脚本（场景）对微信首页（图 1）进行测试，测试尽可能覆盖

场景描述：对微信首页进行测试，检查是否符合要求，包括页面布局、功能链接、图标等方面。

测试步骤：

打开微信首页，检查页面布局是否符合要求，包括标题、搜索框、消息列表、联系人列表等部分；
检查微信首页的功能链接是否正常，包括发现、通讯录、我的、微信支付等链接；
测试微信首页的图标是否正确显示，包括消息图标、通讯录图标、朋友圈图标和微信支付图标等；
检查微信首页的搜索功能是否正常，包括输入关键词、搜索结果展示、查看更多内容等；
检查微信首页的消息列表是否正常，包括消息数量、未读消息提示、消息分类等；
测试微信首页的联系人列表是否正常，包括联系人数量、最近聊天记录、联系人分组等；
检查微信首页的底部导航栏是否正常，包括所选导航项高亮、切换导航项时页面快速响应、导航项顺序是否符合用户使用习惯等。

预期结果：

微信首页的页面布局应符合设计要求，各区块显示清晰；
功能链接应该正确，无误，且点击链接可以正常打开对应的页面；
页面上的图标应该清晰、准确地呈现，无错乱和卡顿；
搜索功能应该准确响应用户输入的关键词，同时展示相关的搜索结果；
消息列表应该按时间排序，最新的消息应该在最上面，并且未读消息应该有红点提示；
联系人列表应该简单、明了，每个联系人应该显示头像、名称和最近的聊天记录；
底部导航栏应该能够无误执行，不会出现意外崩溃、导航项缺失问题等。

若微信首页模块可以用 24 人周完成，可分解为需求分析、设计、编码、测试任务，请按自己的理解给出任务依赖表，并作出条形图（bar chart）。

采用结构化模板描述通过“手机联系人”添加通讯录朋友功能需求

以下是通过结构化模板描述的“手机联系人”添加通讯录朋友功能需求：

功能名称：添加通讯录朋友
描述：用户在使用手机联系人应用时，可以通过添加通讯录朋友功能，将通讯录中的联系人添加为朋友，以便进行更多的沟通和交流。
输入：

用户已登录手机联系人应用，并已授权该应用访问通讯录。
用户已在通讯录中添加了新的联系人，且该联系人的手机号码或微信号已在手机联系人应用中注册。

输出：

通讯录中的联系人已经被添加为朋友，并显示在用户的朋友列表中。

操作流程：

用户打开手机联系人应用，进入主界面。
用户从通讯录中选择要添加为朋友的联系人。
用户选择“添加朋友”功能，系统弹出添加朋友的窗口。
系统根据联系人的手机号码或微信号搜索该用户，并验证联系人身份。
系统提示用户添加朋友信息，并等待用户确认。
用户确认添加朋友信息后，系统将联系人添加到用户的朋友列表中。

约束条件：

用户必须已登录手机联系人应用，并已授权该应用访问通讯录。
通讯录中的联系人必须已添加手机号码或微信号，并已在手机联系人应用中注册。
用户需要通过手机号码或微信号来搜索和验证联系人的身份，确保添加的是正确的朋友。
用户需要确认并同意添加朋友信息，系统才会将联系人添加到朋友列表中。

假设条件：

手机联系人应用已经被安装并成功运行。
用户已成功登录手机联系人应用，且已经授权该应用访问通讯录。
用户已将通讯录中的联系人添加进去，且该联系人的手机号码或微信号已在手机联系人应用中注册。
用户已成功搜索验证联系人身份，并同意添加朋友信息。
系统可以正常连接互联网，以进行搜索和验证功能。

OCP 开闭原则，Open/Close Principle

软件实体应该开放进行扩展，而封闭以进行修改— B. Meyer，1988年/ R。Martin，1996年引用对扩展开放：模块的行为可以被扩展，比如新添加一个子类对修改关闭：模块中的源代码不应该被修改统计数据表明，修正BUG最为频繁，但是影响很小；新增需求数量一般，但造成了绝大多数影响应该编写模块，以便可以扩展它们而无需修改它们