软件工程笔记下

• 从程序到软件☆

章节	知识点
概论☆	软件的定义，特点，生存周期。软件工程的概论。软件危机。

1.☆软件：软件=程序+数据+文档

（1）软件：是指在计算机系统的支持下，能够完成特定功能与性能的包括程序、数据和相关文档的完整集合。

1. 程序：是由程序设计语言所描述的、能为计算机所理解和处理的一组语句序列。

（3）联系：程序是软件的核心部分，软件的功能是执行其中程序实现的。

（4）区别：程序通常是可执行代码，软件包括代码、文档和数据。

2.☆软件的特性：

复杂性、可变性、不可见性、一致性

（1）复杂性：①复杂程度随着程序规模的增加成指数上升。②开发复杂

（2）可变性：在软件开发不同阶段，引入同一个变动需要付出的代价的变化趋势。

（3）不可见性：风险大（4）一致性：维护困难

3.☆软件的特征：

非常复杂、成本高、风险大、维护困难

4.☆软件生存周期：

(1)定义：软件从提出开发开始到开发出系统，运行维护以及最终退役（最终灭亡）所经历的时期

(2)6个阶段：需求分析、软件设计、编码实现、软件测试、部署运行、使用维护

5.软件危机：

(1）☆定义：软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题。

(2）表现：

①　软件开发成本和进度估计不准确②　用户对“已完成的”软件系统不满意的现象经常发生 ③软件质量得不到保证（功能和性能）

④　软件维护困难(多样性 、复杂性、 副作用)  ⑤软件通常没有适当的文档 ⑥软件成本在计算机系统总成本中所占比例升高

⑦　软件开发生产率的提高跟不上计算机应用普及的趋势

(3)根源：

①　对软件这样一类复杂和特殊系统的认识不清 ②没有找到支持软件系统开发的有效方法 ③缺乏成功软件开发实践以及相应的开发经验

6、☆开源软件 列出两个并比较异同:

1.开源软件:

一种源代码可以自由获取和传播的计算机软件，其拥有者通过开源许可证赋予被许可人对软件进行使用、修改和传播。

2.举例：

（1）GPL：

允许任何人观看、修改，并散播程序软件的原始程序代码。发布修改后的版本，就要连通源代码一起公布，不允许修改后和衍生的代码作为闭源的商业软件发布和销售。（自由复制，自由传播，收费传播，修改自由）

（2）BSD ：

是一个给予使用者很大自由的协议。可以自由地使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

第二章 软件工程概述

软件工程	软件工程的目标，原则，中心和三要素。

1.软件工程的定义：☆

（1）把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；

（2）研究（1）中方法的研究。

1）系统的：提供完整和全面的解决方法，包括目标、原则、过程模型、开发活动、开发方法和技术等。

2）规范的：支持各类软件系统的开发，包括语言标准、质量标准、编程标准、方法标准、能力极其改进标准等。

3）可量化：工作量、成本、进度、质量等要素可以量化。

2.☆软件工程的原则：

1）抽象和建模  2）模块化  3）软件重用  4）信息隐藏

5）关注点分离 6）分而治之 7）双向追踪原则8）工具辅助

1）抽象：将与相关开发活动所关注的要素提取出来，不关心要素扔掉，形成与该开发活动相关的软件要素

建模：基于特定的抽象，借助于建模语言（如数据流图、UML等），建立起基于这些抽象的软件模型，进而促进对软件系统的准确理解

2）将软件系统的功能分解和实现为若干个模块，每个模块具有独立的功能，模块之间通过接口进行调用和访问。模块内部高内聚，模块间松耦合

3）在软件开发过程中尽可能利用已有的软件资源和资产（如函数库、类库、构件库、开源软件、代码片段等）来实现软件系统努力开发出可被再次重用的软件资源（如函数、类、构件等）

6）软件开发人员可对复杂软件系统进行分解，形成一组子系统

7）当某个软件制品发生变化时，一方面要追踪这种变化会对那些软件制品产生影响，进而指导相关的开发和维护工作，此为正向追踪；另一方面要追踪产生这种变化的来源，或者说是什么因素导致了该软件制品的变化，明确软件制品发生变化的原因及其合理性，此为反向追踪。

8）利用软件工具来辅助软件开发和维护工作是一项行之有效的方法尽可能地借助计算机工具来辅助软件开发和维护，以降低开发者和维护者的工作负担，提高软件开发和维护效率，提升软件开发及软件制品的质量

1. 软件发展阶段：

(1)程序设计阶段（50~60年代）

(2)程序系统阶段（60~70年代）

(3)软件工程阶段（70～80年代）

(4)第四阶段（80年代至今）

第三章 软件过程模型和开发方法

软件过程模型和开发方法

软件过程模型的定义。软件生存期模型（瀑布模型 、快速原型模型、增量模型、螺旋模型）及各模型的概述、优缺点、适用场合。如何选择过程模型。敏捷开发。能力成熟度模型集成五个级别的名字、每个级别的侧重点。过程和产品的关系。

1. 软件过程：☆

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

1. 软件过程模型的定义：

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

（软件过程模型/软件开发模型/软件生存周期模型/软件工程范型）

1. 软件生存期模型：

分类	模型名称	概述	优点	缺点	场景
生命 周期 模型	瀑布模型	软件开发过程分为需求分析、软件设计、物试和运行维护等步骤和活动，严格按照先后次序和逻辑关系来组织实施。	简单，一目了然，易理解、掌握、应用和管理	需求变更；阻塞；不能满足需求	需求易于定义、不易变动、较为明确、可预先定义的软件系统
演化 过程 模型	原型模型	指在设计或开发过程中通过搭建一个部分或完整的模型,来展示最终产品的外观、功能和特性。	①提高设计质量；②加快开发进程；③减少项目成本；④增强用户参与；⑤降低开发风险。	①建需时间和资源；②对环境和成本的敏感性；③需用户密切配合；④可能致质量低；⑤限制开发创新。	理解需求难以表述清楚、不易导出和获取、持续变动的应用
增量 过程 模型	增量模型	一种渐进地开发逐步完善的软件版本的模型，该模型一般首先开发产品的基本部分，然后再逐步开发产品的附加部分。			需求变动不大、较为明确、可预先定义的应用
	迭代模型				需求变动大、较为明确、可预先定义的的应用
	螺旋模型				开发风险大，需求难以确定的应用

（1）生命周期模型：

1.1瀑布模型☆

⑴概念：

瀑布模型将软件开发过程分为需求分析、软件设计、物试和运行维护等步骤和活动，严格按照先后次序和逻辑关系来组织实施。

(2)指导思想：提供系统性指导

(3)特点：

①与软件生命周期相互一致；②每个活动结束后需要评审；

③相邻活动间存在因果关系。

(4)优点：

简单，一目了然，易理解、掌握、应用和管理。

(5)缺点：

①不适应需求经常发生变更的环境；②流程顺序严格，各阶段依赖性强会导致工作中发生“阻塞”状态

③完全依赖于书面的规格说明，软件产品不能真正满足用户的需要➃用户只能通过文档来了解产品是什么样

⑸适用场景：适合于需求易于定义、不易变动的软件系统。

(2)演变过程模型：

2.1.原型模型☆

⑴概念：

原型模型是指在设计或开发过程中通过搭建一个部分或完整的模型,来展示最终产品的外观、功能和特性。

(2)指导思想：以原型为媒介指导用户的需求导出和评价

(3)特点：

①软件原型作为交流载体和媒介；②支持用户参与到软件开发中；

③持续、渐进地导出用户要求。

(4)优点：

①提高设计质量；②加快开发进程；③减少项目成本；

④增强用户参与；⑤降低开发风险。

(5)缺点：

①建立原型需要时间和资源；②对环境和成本的敏感性；③需要与用户密切配合；

④可能导致质量低下；⑤限制开发人员的创新。

(6)适用场景：适合于需求难导出、不易确定且持续变动的软件。

1. 增量过程模型：

3.1增量模型☆

(1)概念：

一种渐进地开发逐步完善的软件版本的模型，该模型一般

首先开发产品的基本部分，然后再逐步开发产品的附加部分。

(2)指导思想：快速交付和并行开发

(3)优点：

①显著地克服瀑布模型缺点、减少由于软件需求不明确而给开发工作带来风险；缩短产品提交时间

②用户有充裕的时间学习适应新产品，减少一个全新的软件给客户组织带来的冲击。

(4)缺点：

①在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。软件体系结构必须是开放的。

②开发人员既要把软件系统看作整体。又要看成可独立的构件，因此相互矛盾。除非开发人员有足够的技术能力协调好。

③多个构件并行开发，具有无法集成的风险。

(5)适用场景：需求变动不大、较为明确、可预先定义的应用

3.2迭代模型

1. 概述：

是一种支持面向对象开发的模型。体现迭代和无间隙特征。

①迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中，不断加入演进的内容。②无间隙：开发活动之间不存在明显的边界。

(2)指导思想：多次迭代，每次仅针对部分明确软件需求

(3)优点：

(4)缺点：

(5)适用场景：需求变动大、难以一次性说清楚的应用

3.3.螺旋模型☆

(1)概述：沿着螺线旋转，在四个象限上分别表达了四个方面的活动：

①制定计划-确定目标，选择方案，选定完成目标的策略。

②风险分析-风险角度，分析该策略。

③实施工程-实施软件开发。

④客户评估-评价开发工作，提出修正建议。

1. 指导思想：

集成迭代模型和原型模型，引入风险分析

(3)特点 ：

瀑布模型+快速原型+风险分析的迭代过程

(4)优点：

适用于高风险的大型软件，由于软件随着过程的推进而变化，在每一个演进层次上，开发者和客户都可以更好地理解和应对风险。

(5)缺点：

风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大。

(6)适用场景：

主要适用于内部开发的大规模软件项目

4.软件过程模型的选择

(1)考虑软件项目的特点，

尤其是所开发软件的业务特点，如业务领域是否明确、软件需求是否易于确定、用户需求是否会经常性变化等等是否可以预估到潜在的软件开发风险

(2)软件开发团队的水平

需要结合软件开发团队的能力和水平来选择过程模型，以防开发团队和管理人员无法掌控和驾驭过程模型

(3)分析软件过程模型特点

优缺点以及适合的场所

5、敏捷方法

(1)理念：

一种轻量级软件开发方法。

主张软件开发要以代码为中心，快速、轻巧和主动应对需求变化，持续及时交付可运行的软件系统。

提供了一组思想和策略，指导快速响应用户需求的变化，快速交付可运行的软件制品。

(2)价值观：

①较之于过程和工具，应更加重视人和交互的价值；

②较之于面面俱到文档，应更加重视可运行软件系统的价值；

③较之于合同谈判，应更加重视客户合作的价值；

④较之于遵循计划，应更加重视响应用户需求变化的价值。

(3)体现思想：

①强化可运行软件，弱化文档

②以适应变化为目的来推进开发

③以人为本

敏捷方法很多,包括极限编程(XP)、 Scrum方法、测试驱动开发(FDD)等多种方法，

• 软件需求

软件需求	需求的定义、需求的特性。需求的分类(功能性需求、非功能性需求)。 需求分析的四个步骤，每个步骤的定义。
	结构化分析方法的分析策略是自顶向下逐步求精。结构化分析建立的模型的核心，围绕该核心建立的三种图及对应的规格说明的名字（分别属于对什么建模）。会画数据流图。
	面向对象的分析建立哪三种模型，分别对应UML中的什么图（只需要知道图的 名字）。用例图由哪三个元素构成，每个元素的定义。会画用例图。

1. 软件需求☆

1. 定义：开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求，

即：确定软件系统要做什么。

(2)IEEE定义：

①用户为了解决问题或达到某些目标所需要的条件或能力；

②系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需具备的条件或能力；

③对①或②中的一个条件或一种能力的一种文档化表述。

2、软件需求的类别☆

1.软件功能性需求：

能够完成的功能及在某些场景下可展现的外部可见行为或效果。

2.非功能需求：

(1)软件质量需求：

外部质量属性，外部可展现的，用户、客户等会非常关心，如运行性能、可靠性、易用性等；内部质量属性，隐藏在内部的，软件开发工程师会非常关心，如可扩展性、可维护性、可理解性。

①外部质量属性，外部可展现的，用户、客户等会非常关心，如运行性能、可靠性、易用性等

②内部质量属性，隐藏在内部的，软件开发工程师会非常关心，如可扩展性、可维护性、可理解性

(2)软件开发约束需求：

开发成本、交付进度、技术选型、遵循标准等方面提出的要求。

分类	内涵	关注的利益相关者
功能需求	软件具有的功能、行为和服务	用户、客户、开发者群体
软件质量需求	内部质量需求	开发者群体
	外部质量需求	用户、客户、开发者群体、其他系统
软件开发约束需求	软件开发需满足的要求	客户、开发者群体

3、软件需求的重要性

(1)软件的价值所在

(2)软件开发的基础和前提

(3)软件验收的标准和依据

4、软件需求的特性

(1)隐式性：来自于利益相关方，它隐式存在。很难辨别，甚至会遗漏掉。

(2)隐晦性：在利益相关方的潜意识之中，不易于表达出来，难以获取。

所表达的软件需求存在模糊性、歧义性、二义性。

(3)多源性：存在多个的利益相关方。存在相冲突和不一致的软件需求。

(4)易变性：用户对软件的期望和要求也会经常性地发生变化。在整个生命周期都会发生变化。

(5)领域知识的相关性：

软件需求的内涵与软件所在领域的知识息息相关

(6)价值不均性：

不同的软件需求对于客户或用户而言所体现的价值是不一样的

主要和次要、核心和外围需求

1. 需求工程

用工程的理念和方法来指导软件需求实践

提供了一系列的过程、策略、方法学和工具

帮助需求工程师加强对业务或领域问题及其环境的理解，获取和分析软件需求

指导软件需求的文档化和评审，以尽可能获得准确、一致和完整的软件需求，产生软件需求的相关软件制品

①知识密集型工作，需要交叉多学科的知识②多方共同参与

③需求获取的多种形式和源头④持续迭代和逐步推进

1. 简述需求工程的一般性过程

(1).获取软件需求

获得软件利益相关者对软件的期望和要求，进而获取初步软件需求。

(2).分析软件需求

在初步软件需求的基础上，对软件需求进行精化、建模和分析，获得软件需求在功能、行为、特征和约束等方面更为详细的信息，发现并解决软件需求中潜在的问题，产生准确、一致和完整的软件需求及其描述。

(3).文档化软件需求

在获取和分析软件需求及其成果的基础上，撰写软件需求文档，产生软件需求规格说明书。

(4).确认和验证软件需求

对前面工作所产生的软件需求模型和文档进行评审，让软件系统的利益相关者确认和验证软件需求，发现问题和缺陷，并加以解决和纠正，确保经评审后的软件需求模型和文档符合利益相关者的诉求并满足质量要求。

(5).管理软件需求

由于软件需求工程贯穿于整个软件生存周期，软件需求会持续发生变化，并且需求变化会对软件开发和运维产生重要的影响，因此必须对软件需求变化以及相应的软件需求制品进行有效的管理。

• 获取软件需求

1、获取软件需求：是指得到或产生软件需求

2、获取软件需求的方式：

3、获取软件需求的方法：

（1）访谈和会议：

召开相关的会议，走访相关的人员。

参加的人员包括：用户、客户、需求分析人员、质量保证人员等等；

（2）调查问卷：

设计调查问卷：了解业务流程、实际操作过程，用户的期望和要求。

调查对象：应用领域中不同角色用户口如何利用调查问卷。

（3）获现场观摩：业务过程、步骤和输出，业务工作流程和细节；

（4）分析业务资料：收集重要的资料，阅读和分析与业务相关的文档和资料；

（5）软件原型：

需求工程师根据用户初步需求描述，快速构造出一个可运行的软件原型。

软件原型作为需求工程师和用户之间的交流媒介，有助于直观地展示软件需求，激发用户投入到需求讨论和导出之中，因而是一项极为有效的需求获取和分析方法。

（6）群体化方法：

让互联网上的海量和开放群体参与到获取软件需求的工作中来，提出他们对软件需求的想法，并通过组织、汇聚和筛选，从中遴选出有价值的软件需求。集思广益有助于获得超出开发团队和用户常规想定的软件需求。

1. 获取软件需求的过程

 1.明确问题和基于软件的解决方案

明确待开发软件系统欲解决什么样的问题，给出清晰的问题描述；明确如何通过软件来解决问题，需要集成哪些其他的系统（包括物理系统或遗留系统）、与它们进行怎样的交互（包括数据和服务的共享）等；界定软件系统的目标和范围，讲清楚软件系统要做什么、不做什么。

2. 导出和构思初步软件需求

在识别软件利益相关者的基础上，从软件利益相关者那里导出软件需求；或者针对软件欲解决的问题构思出软件系统的需求，形成初步的软件需求，包括功能需求和非功能需求。

3. 描述初步软件需求

描述所获得的软件需求，详细刻画和记录软件需求的具体内涵，促进不同人员围绕软件需求进行交流，支持后续的需求分析工作。需求工程师可采用多种方式来描述软件需求，如自然语言、软件原型、用例模型等。

4.评审初步软件需求

需求工程师组织多方人员（包括用户和客户等）评审初步软件需求及其描述，发现和解决软件需求中存在的各类问题，确保初步软件需求的质量。

1. 获取软件需求可行性分析

技术可行性+设备可行性+进度可行性+成本可行性+商业可行性（商业价值）+社会可行性

• 分析软件需求

1、分析软件需求的任务

1. 精化软件需求（2）建立软件需求模型（3）分析需求间的关系

（4）发现和解决需求问题（5)撰写和评审软件需求

文档

2、支持需求建模和分析的UML图

软件需求模型

3、简述顺序图的作用与组成元素

1. 作用：描述对象间的消息交互序列
2. 组成元素：

1）纵向：时间轴，对象及其生命线(虚线)，活跃期(长条矩形)  2）横向：对象间的消息传递

3）对象：[对象名] : [类名]

4）消息传递：对象生命线间的有向边

①同步消息：发送者等待接收者将消息处理完后再继续

②异步消息：发送者在发送完消息后不等待接收方即继续自己的处理

③自消息：一个对象发送给自身的消息

④返回消息：某条消息处理已经完成，处理结果沿返回消息传回

⑤创建消息和销毁消息：消息传递目标对象的创建和删除

4、简述类图的作用与组成元素

（1）作用：描述系统的类构成，刻画系统的静态组成结构

（2）组成元素：

1）结点：表示系统中的类（或接口）及其属性和操作

2）边：类之间的关系

（3）属性的表示：[可见性] 名称 [: 类型] [多重性] [= 初值]  [{约束特性}]

1）可见性：公开(+)、保护(#)、私有(-)

2）多重性：属性取值数量, 如1，0..1，0..* ，1..*，*

3）约束特性：可更改性：{readOnly}、顺序性： {ordered}、唯一性： {bag}、静态性：{static}

（4）接口：一种不包含操作实现部分的特殊类

1）接口的形式：①供给接口: 对外提供的接口②需求接口: 需要使用的接口

（5）类间的关系：

    1）关联：类间的逻辑联系

2）聚合：部分类对象是多个整体类对象的组成

3）组合：部分类对象只能位于一个整体类对象中

4）依赖：有语义上关系且一个类对象变化会导致另一类对象作相应修改

5）实现：表示一个类实现了另一个类中定义的对外接口

6）继承：子类继承父类所有可继承的特性，且可通过添加新特性或覆盖父类中的原有特性

5、简述状态图的作用与组成元素

（1）作用：

描述实体（对象、系统）在事件刺激下的反应式动态行为及其导致的状态变化

刻画了实体的可能状态、每个状态下可响应事件、响应动作、状态迁移

1. 基本改念：

1）状态：对象属性取值构成的一个约束条件，不同状态下对象对事件的响应行为完全一样

2）事件：某时刻点发生、需要关注的瞬时刺激或触动

消息型事件(同步)：其他对象发来消息

信号型事件(异步)：其他对象传来异步信号

时间型事件：到达特定时间点

条件型事件：对象属性取值满足特定条件

1. 动作：

计算过程，位于迁移边上，简单执行时间短

4）活动：

计算过程，位于状态中，复杂执行时间长

1. 组成：

①节点：状态②边：迁移，即状态间因事件刺激而触发的状态变化

初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。

中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分

1. 分析软件需求的过程

1. 分析和确定软件需求优先级

分析软件需求重要性

分析软件需求优先级

确定用例分析和实现的次序

考虑：重要性和实际需求

1. 分析软件需求的重要性

1）从用户和客户的视角，软件需求的重要性是不一样的

2）核心软件需求：

在解决问题方面起到举足轻重的作用，提供了软件系统所特有的功能和服务，体现了软件系统的特色和优势

3）外围软件需求：

提供了次要、辅助性的功能和服务

第七章 软件设计基础

软件设计基础	软件设计包含的两类活动。创新设计不属于软件设计。软件的质量属性。各种设计技术（模块化为什么不能无限划分模块、信息隐藏原则的定义、重构的定义、抽象、设计模式、功能独立（不要求背7种内聚和7种耦合）、细化）。程序结构的深度、宽度、扇入数、扇出数。信息隐蔽原则有利于提高模块的内聚性。完整的设计规格包括哪四种设计模型。
	软件体系架构（5种架构风格、B/S与C/S架构）。用户界面设计的三条原则。 用户界面设计由一系列的分析开始（三种分析的内容）。
	结构化程序设计的概念。详细设计（会画流程图、伪代码、NS图、PAD图）。 流程图的主要缺点。

1. 软件设计

针对软件需求，综合考虑各种制约因素，探究软件实现的解决方案

1. 软件设计是需求分析和软件实现间的桥梁

1. 软件设计的一般性过程

1. 软件设计的约束和原则

①抽象与逐步求精                ②模块化，高内聚度、低耦合度

③信息隐藏                      ④多视点和关注点分离

⑤软件重用                      ⑥迭代设计

⑦可追踪性

1. 抽象
2. 模块化、高内聚度和低耦合度原则（分而治之）

将软件系统的整体结构分解为一组相关模块（模块：包、子系统、构件、类、方法等等）

每个模块实现单一的功能。通过模块之间的交互来组装模块，形成整体框架

1. 耦合性

1. 软件体系结构设计

• 软件体系结构模型的表示方法

1. 包图

（1）功效：刻画包间的构成和依赖关系

（2）图的构成：节点：包。边：包间的关系

（3）包间的关系：组成和依赖

（4）包：一组具有逻辑关联的UML模型元素（例如用例、类等）、模型图（用例图、类图、交互图、状态图、活动图等），以及其他的包。

包在模型管理过程中是配置管理的基本单元，同时也为访问控制提供基本手段

1. 包的作用

①作为软件模型的组织单元

②作为模型管理的基本单元

③作为系统高层结构中的组成元素。

④作为访问控制的基本手段

1. 部署图

（1）功效：

表示软件系统可执行工件(artifact)在运行环境中的部署和分布情况

（工件是指软件中相对独立的物理实现单元，如Java类库文件）

（2）图的构成①节点：计算节点、工件、构件②边：通信和依赖

（3）两种部署图

①逻辑层面的描述性部署图描述软件的逻辑布局

②物理层面的实例性部署图针对具体运行环境和特定的系统配置描述软件系统的物理部署情况

1. 构件图

（1）功效：描述软件系统中构件及构件间的构成和依赖关系

（2）图的构成：

①节点：构件，具有对外接口、可分离和独立功能物理模块②边：构件间的依赖关系

（3）构件

一个或者多个可独立部署的执行码文件

具有精确定义的供给接口和需求接口

可分离，接口和实现分离

可替换，构件实例可被任何实现相同接口的同一构件实例所替换

（4）接口

一组操作 和/或 属性的说明（不含操作的实现），它用作服务提供方和使用方之间的协议

每个构件还可以定义一些端口（port），每个端口绑定了一组供给接口和/或需求接口

接口由类或构件实现