软件工程概论

第一章 概述

软件

软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据，从软件的内容来看，软件更像是一种嵌入式的数字化知识，其形成是一个通过交互对话和抽象理解而不断演化的过程，根据软件服务对象的范围，一般分为通用和定制两种。

• 通用软件(Generic Software)：由软件开发组织开发、面向市场用户公开销售的独立运行系统（优点：一次开发，多次出售 缺点：有风险）
• 定制软件(Customized Software )：由某个特定用户委托、软件开发组织在合同的约束下开发的软件（优点：满足用户个性化需求 缺点：重复利用性差）

软件的特性

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

软件是复杂的，软件是人类思维和智能的一种延伸和在异体上的再现，远比任何以往人类的创造物都要复杂的多，软件的复杂性是软件的固有属性、本质特性。

软件是不可见的，软件是客观世界空间和计算机空间之间的一种逻辑实体，不具有物理的形体特征。

软件是不断变化的，它需要随着应用、硬件、用户和社会等各种因素的变化而不断的被修改和扩展。

软件必须遵从人为的惯例并适应已有的技术和系统，软件需要随接口的不同而改变，随时间的推移而变化，而这些变化是不同的人设计的结果，许多复杂性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂特性。

软件工程三要素

软件工程以关注软件质量为目标，包括过程、方法和工具三要素

• 过程 支持软件生命周期的所有活动
• 方法 为软件开发过程提供“如何做”的技术
• 工具 为软件开发方法提供自动的或半自动的软件支撑环境

ISO9126软件质量的六个一级特性

功能性、可靠性、可使用性、有效性、可维护性、可移植性

• 功能性：在指定条件下使用时，软件产品提供满足明确和隐含需求功能的能力；
• 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力(在规定的条件下，在规定的时间内，软件不引起系统失效的概率)；
• 易用性（可使用性）：在指定条件下使用时，软件产品被理解、学习、使用及其吸引用户的能力；
• 效率（有效性）：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力；
• 可维护性：软件产品可被修改的能力，修改可能包括修正、改进或者适应环境、需求和功能规约的变化；
• 可移植性：软件产品从一种环境迁移到另一种环境的能力。

第二章 软件过程

软件过程

软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。

软件过程的基本活动

问题提出、软件需求规格说明、软件设计、软件实现、软件确认、软件演化

• 问题提出（可行性分析）：对开发任务进行调研和分析，研究系统的可行性和可能的解决方案，确定开发总目标和范围。
• 软件需求规格说明：软件需求规格说明描述软件功能、列出约束条件、定义软件的输入和输出接口。
• 软件设计：软件设计是根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现算法、数据结构及其接口等，编写软件设计说明书。
• 软件实现：软件实现是将所设计的各个子系统编写成计算机可接受的程序代码。
• 软件确认：检查和验证所开发的系统是否符合用户的期望。
• 软件演化：软件的内在本质是灵活的和可变的。随着业务需求的变化，软件必须进化和变更。尽管在开发过程和演化（维护）过程之间存在划分，但是现实中全新的系统越来越少。

软件过程模型

软件过程模型描述软件过程的整体框架，是软件过程的一种抽象表示。

软件过程模型包括：瀑布模型、快速原型模型、增量模型、螺旋模型、形式化方法模型、基于组件的开发模型

• 瀑布模型 将软件过程划分为需求定义与分析、软件设计、软件实现、软件测试、软件运行与维护等一系列基本活动。以上活动自上而下、相互衔接的固定顺序，如瀑布流水，逐级下落。

• 快速原型模型 快速原型模型的第一步是迅速构建一个可以运行的软件原型，实现用户与系统的交互，由用户对该原型进行评价，进一步细化待开发软件需求。结果逐步调整使其满足用户的要求之后，开发人员可以将用户的真正需求确定下来。第二步则在第一步的基础上开发用户满意的软件。（特点：有效适应用户需求的变化不知循环多少次，进度难以控制）

• 增量模型 增量模型在各个阶段并不一定交付一个可运行的完整产品，而是交付满足用户需求的一个子集。第一个增量往往是实现基本需求的核心产品，交付用户使用后，经过评价形成下一个增量的开发计划，其中包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

• 螺旋模型 将瀑布模型和快速原型模型结合起来，强调了风险分析，特别适合大型复杂软件系统（优点：风险驱动（关注软件的重用、关注早期错误的消除、将质量目标放在首位、将开发阶段与维护阶段结合在一起）（缺点：需要风险评估的经验适应内部大规模软件开发）

• 形式化方法模型 首先将软件需求描述提炼成采用数学符号表达的形式化描述；然后经过一系列的形式化转换将形式化描述转换成可执行程序；最后将整个系统集成起来测试。 (优点：由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性) (缺点：开发人员需要具备一定技能并经过特殊训练;形式化描述和转换是一项费时费力的工作,成本高，质量不一定高;现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述)

第三章 软件项目管理

项目管理(PM)

就是在项目活动中运用相关知识, 技能, 工具和技术满足项目的要求。

项目管理的五个阶段

启动、计划、监督、控制、收尾

• 启动: 确定项目范围、组建项目团队、建立项目环境
• 计划: 确定项目活动、预算项目成本、制定进度计划
• 实施（监督+控制）: 监控项目执行、管理项目风险、控制项目变更
• 收尾: 客户验收项目、安装培训软件、总结项目经验

Albrecht的软件信息域的5个基本特征

• 外部输入：用户进行添加或修改的表格。
• 外部输出：产生的报表输出和屏幕输出。
• 外部查询：独立查询。
• 内部逻辑文件：软件修改或保存的逻辑纪录集合。
• 外部接口：与其他系统进行信息交换或共享的 文件。

软件风险

一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。

• 特点:事先难以确定；一旦发生将带来损失，影响项目实施，甚至会导致项目失败

• 类别:软件规模、商业影响、客户特性、软件过程、开发技术、开发环境、开发人员

软件风险管理过程

风险识别→风险评估→风险管理计划→风险监控

风险识别是试图采用系统化的方法，识别特定项目已知和可预测的风险 风险识别的常用方法是建立风险条目检查表，即利用一组提问来帮助项目管理者了解在项目和技术方面的一些风险。

第四章 需求工程

不同角度的需求

• 业务需求：定义了软件的远景和范围。
• 用户需求：反映了用户使用该系统需要完成的任务。
• 功能需求：系统需要具备的功能。
• 非功能需求：系统应该具备的性能。
• 系统需求：面向开发人员、详细描述系统应该做什么。 软件的功能需求必须根据用户需求来考虑，而且应该与业务需求定义的目标相一致

功能需求

描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节

非功能需求

是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，包括过程需求、产品需求和外部需求等类型。

需求工程

需求工程是应用已证实有效的原理和方法，并通过合适的工具和符号，系统地描述出待开发系统及其行为特征和相关约束。

• 需求管理：在开发过程中有效地管理和控制需求变更。
• 需求获取：开发人员聆听客户的需求，观察用户的行为；
• 需求分析：分析和整理所收集的用户需求；
• 需求规格说明：以文档形式，精确地阐述一个软件系统 必须提供的功能和性能以及它所要考虑的限制条件；
• 需求验证：使用评审和商议等有效手段对其进行验证， 最终形成一个需求基线；

  需求获取技术

用户面谈、需求专题讨论会、现场考察、原型化方法、基于用例的方法 基于用例的方法 通过用例模型，明确系统功能

特点：以任务和用户为中心、有助于客户了解系统功能、有助于开发人员理解用户需求、可以采用面向对象分析和设计方法将用例转化为设计模型

第六章 面向对象基础

关联

关联是对象属性之间的静态联系，它通过对象的属性来表现对象之间的依赖关系

关联关系

关联关系是类与类之间最常用的一种关系，它是一种结构化关系，表示has-a关系，往往表现为B作为A的属性存在（A关联B）

依赖关系

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。表示要做一件事情，离不开某个对象，往往表现为B作为A的方法参数存在（A依赖B）

聚合关系

聚合关系表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。

第七章 面向对象分析

分析类

在分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象，分析类直接与应用逻辑相关，而不关注技术实现的问题，分析类从软件的功能需求来看分为实体类、边界类和控制类

• 实体类：表示系统存储和管理的永久信息 entity
• 边界类：表示参与者与系统之间的交互 boundry
• 控制类：表示系统在运行过程中的业务控制逻辑 control（一个用例可有多个控制类）

分析活动

理解用例模型→识别分析类→定义交互行为→建立分析类→评审分析模型

面向对象的分析模型

• 功能模型：由用例和场景表示
• 对象模型：由类图和对象图表示
• 动态模型：由状态图和顺序图表示

第八章 面向对象设计

设计原则

模块化、高内聚、低耦合、复用性

软件体系结构

涉及软件系统的总体组织、全局控制、数据存取以及子系统之间的通信协议等。

典型软件体系结构：仓库体系结构、分层体系结构、MVC体系结构、客户机/服务器体系结构、管道和过滤体系结构

• 仓库体系结构：在仓库体系结构中，有两种不同的软件部件：一个表示当前的中心数据结构和一组相互独立的处理中心数据的子系统。仓库体系结构无需在子系统之间进行数据转换，因而是一种共享大量数据的高效方法，而且只要与共享模型一致，新的子系统就可以很容易的增加到系统中

• 分层体系结构：层次化是一种概念，它将软件设计组织成为类或组件的层次或集合，在同一个层次上的类或组建完成一个特定的目的，良好的层次结构可以易与系统的扩建与维护，不同的层次之间通过接口进行通信

• MVC子系统：在MVC体系结构中，子系统划分成不同的三种类型：模型子系统负责存储系统的中心数据；视图子系统负责将模型中的数据展示给用户；控制器子系统负责管理与用户的交互控制

• 客户机/服务器子系统：在客户机/服务器体系结构中，作为服务器的子系统为其他客户的子系统提供服务，作为客户机的子系统负责与用户的交互。

• 管道和过滤体系结构：在管道和过滤体系结构中，数据在不同的子系统之间流动，每一个子系统处理输入的一组数据，并将处理结构输出给其他子系统。

详细设计

方法建模、属性建模、状态建模、关系建模

泛化关系

也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。

设计模式

广义讲，软件设计模式是可解决一类软件问题并能重复使用的软件设计方案；狭义讲，设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。是在类和对象的层次描述的可重复使用的软件设计问题的解决方案。 分类

• 应用角度（3）
  • 创建型模式（用来创建对象的模式，抽象了实力化过程）
  • 结构型模式（讨论的是类和对象的结构，采用继承机制来组合接口）
  • 行为型模式（着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流程）
• 模式范围（2）
  • 类模式

  • 对象模式 - Factory模式（工厂模式） 对象型创建模式

    父类负责定义创建对象的公共接口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成。

    - Adapter模式（适配器模式）
  
      将一个类的接口适配成用户所期待的接口。一个适配器允许因为接口不兼容而不能在一起工作的类在一起工作。做法是将类自己的接口包装在一个已经存在的类中。
    - Bridge模式（桥梁模式）
  	
      将问题的抽象和实现分离开来实现，通过用聚合代替类继承来解决子类爆炸性增长的问题。
  	  
    - Façade模式（外观模式）
  	
      为子系统提供一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。
  

第十章 软件测试

• 软件产品在交付使用前，一般需要经过单元测试、集成测试、确认测试和系统测试

单元测试任务：

• 模块接口测试（单元测试的基础，主要检查数据能否正确地通过模块）
• 模块局部数据结构测试（局部数据结构往往是错误的根源）
• 模块中所有独立执行通路测试
• 模块的各条错误处理通路测试
• 模块边界条件测试

集成测试

将所有模块按照设计要求组装成一个完整的系统而进行的测试，也称组装测试或联合测试，目的是发现与接口有关的各种错误方法 非增量式测试（把所有的模块按设计要求组装在一起进行的整体测试）、增量式测试（逐个把模块组装到已经测试过的模块上去，进行集成测试。每加入一个新模块进行一次集成的测试，重复此过程直至程序组装完毕）、

确认测试

通过集成测试后，软件已经完全组装了起来，接口方面的错误也已排除，这时就可以对软件进行最后的确认测试。

• 其任务是检查软件能否按合同要求进行工作，即是否满足需求规格说明书中的确认标准。
• 确认测试方法：黑盒测试法。
• 确认测试的2种结果
  • 软件功能和性能指标满足软件需求说明的要求，用户可接受。
  • 软件不满足软件需求说明的要求，用户无法接受。
• 步骤
  • 有效性测试：检查软件能否按合同要求进行工作，即是否满足需求规格说明书中的确认标准。
  • 软件配置复查：保证软件配置齐全。

系统测试

把软件、硬件和环境连接在一起，在实际运行环境下进行全面测试，验证系统各部件是否都能够正确工作并完成任务。

• 恢复测试（主要检查系统的容错能力）
• 安全测试（主要检查系统对非法侵入的防范能力）
• 强度测试（强度测试检查程序对异常情况的抵抗能力；是检查系 统在极限状态下运行的时候性能下降的幅度是否在允许的范围内）
• 性能测试

软件调试

• 调试方法
  • 简单的调试方法
  • 归纳法调试
  • 演绎法调试
  • 回溯法调试

黑盒测试

该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求说明书，检查程序是否满足功能要求。

方法：等价类划分、边界值分析、错误推测等

白盒测试

该方法把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错、实际的运行状态与预期的状态是否一致。

方法：逻辑覆盖、基本路径测试

等价类划分方法

1) 如果某个输入条件规定了取值范围或值的个数，则可确定一个合理的等价类(输入值或数在此范围内)和两个不合理的等价类（输入值或数不在此范围） 2) 如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许的输入值是一个合理等价类，此外还有一个不合理等价类（任何一个不允许的输入值） 3) 如果规定了输入数据必须遵循的规则，可确定一个合理等价类（符合规则）和若干个不合理等价类（从各种不同角度违反规则） 4) 如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类

第十一章 软件演化

软件维护

软件被投入运行使用后人们对软件产品所进行的修改 目的：为了修改软件缺陷或增加新的功能而对软件进行的变更。 软件变更通常发生在局部，不会改变整个结构

• 类型（软件维护的不同原因）
  • 改正性维护：修改软件中的缺陷或不足
  • 适应性维护：修改软件使其适应不同的操作环境，包括硬件变化、操作系统变化、数据库更换等其他支持软件变化。
• 完善性维护：增加或修改系统的功能，使其适应业务的变化。

特点：受开发过程影响大、维护困难多、维护成本高

过程：维护申请→维护分类→影响分析→版本规划→变更实施→软件发布

软件再工程

软件再工程以系统理解为基础，结合反向工程、重构和正向工程等方法，将现有系统重新构造成为新的形式。形象地说，就是“把今天的方法学用于昨天的系统以满足明天的需要”。

反向工程

• 是一种设计恢复过程，它是从现有系统的源代码中抽取数据结构、体系结构和程序设计信息。
• 可以使用CASE工具自动处理，也可以手工分析。
• 尽量找出程序的基本结构，并在进一步理解的基础上添加一些设计信息，逐步抽象建立系统设计模型。

正向工程

• 利用从现有程序中恢复的设计信息而修改或重构现有系统，以提高系统的整体质量。
• 通常正向工程并不是简单地构造一个与原有系统功能等价的系统，而是结合新的用户需求和软件技术扩展原有系统的功能和性能。

---