02333 软件工程 ✒️

绪论

软件工程概念的提出与发展

从事软件开发实践和软件工程项目管理的思想基础：正确认识软件开发

软件危机

20世纪60年代以来，随着计算机的广泛应用，软件生产率、软件质量满足不了社会发展的需求，成为社会、经济发展的制约因素 ，人们通常把这些现象称为软件危机

软件工程概念的提出

其目的是倡导以工程的原理、原则和方法进行软件开发以期解决出现的“软件危机"

软件工程这一术语首次出现在1968年的 NATO（北大西洋公约组织） 会议上

软件工程的定义

软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的 学科

软件工程的发展

20世纪60年代末到80年代初

• 主要成果：提出瀑布模型，开发了诸多过程式语言（如c语言、Pascal语言）和开发方法 （如Jackson方法、结构化方法）、开发了一些支持工具（调试工具、测试工具）等
• 特征：前期主要研究系统实现技术，后期开始关注软件质量和软件工程管理

20世纪80年代以来

• 主要成果：提出 《软件生存周期过程》、开展计算机辅助工程（CASE）、面向对象语言（如Smalltalk、C++）、 提出面向对象软件开发方法等
• 特征：开展了一系列有关软件生产技术，特别是软件复用技术和软件生产管理的研究和实践

软件开发的本质

计算机软件

一般是指计算机系统中的程序及其文档

• 程序是对计算机任务的处理对象和处理规则的描述
• 文档是为了理解程序所需的阐述性资料

本质

客户需求 $\Rightarrow$ 具体实现

软件开发的目标是将问题域中的概念映射为运行平台层面上的概念，把问题域中的处理逻辑映射为运行平台层面上的处理逻辑

软件开发就是要弥补问题域与运行平台之间的距离，人从而在二者之间直接进行映射

系统建模

• 概念：不同抽象层术语之间的映射，以及不同抽象层处理逻辑之间的映射，实现这一映射的基本途径
• 内容：
  • 一是如何实现这样的映射，这是技术层面的问题
  • 二是如何管理这样的映射，以保障映射的有效性和正确性，这是管理层面的问题

模型

简单地说，是待建系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节

进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述

在软件开发中，软件系统模型大体上可分为两类：概念模型和软件模型。分层的基本动机是为了控制开发的复杂性

• 在需求层上创建的系统概念模型是对客观事物系统的抽象即标识要解决的问题，或称问题定义
• 软件模型又可进一步分为设计模型、实现模型和部署模型等

软件需求及其规约

需求及其获取

软件需求是任何软件工程项目的基础！

定义

一个需求描述了待开发产品、系统功能上的能力、性能参数或其他性质

5个基本性质

1. 必要的：该需求是用户所要求的
2. 无歧义的：该需求只能用一种方式解释
3. 可测的：该需求是可进行测试的
4. 可跟踪的：该需求可从一个开发阶段跟踪到另一个阶段
5. 可测量的：该需求是可测量的

分类

需求分类	细分	描述
功能需求		规约了系统或系统构件必须执行的能力，是整个需求的主体
非功能需求	性能需求	规约了一个系统或构件在性能方面必须具有的一些特性
	外部接口需求	规约了系统或构件必须与之交互的用户、硬件、软件或数据库元素 其中也可能规约交互格式、时间或其他因素
	设计约束	限制了软件系统或构件的设计方案的范围 需考虑法规政策、硬件限制等
	质量属性	规约了软件产品所具有的一个性质（包括功能和其他需求） 必须达到其质量方面一个所期望的水平

需求发现技术

• 自悟：需求人员把自己作为系统的最终用户，审视该系统并提出问题：如果是我使用这一系统，则我需要...
• 交谈：为确定系统应该提供的功能，需求人员通过提出问题/用户回答这一方式，直接询问用户需要的是一个什么样的系统
• 观察：通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建立的新系统与现存系统、过程以及工作方法间必须进行的交互
• 小组会：举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求
• 提炼：复审技术文档，并提取相关信息

需求规约

定义

需求规约是一个软件产项/产品/系统所有需求陈述的正式文档，它表达了一个软件产项/产品/系统的概念模型

4个基本性质

• 重要性和稳定性程度：按需求的重要性和稳定性对需求进行分级，如基本需求、可选需求和期望需求
• 可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求
• 完整的：没有被遗漏的需求
• 一致的：不存在互斥的需求

格式

1. 引言
   1.1 目的
   1.2 范围
   1.3 定义，缩略语
   1.4 参考文献
   1.5 概述
2. 总体描述
   2.1 产品概述
   2.2 产品功能
   2.3 用户特性
   2.4 约束
   2.5 假设和依赖
3. 特定需求 【文档的技术核心】

附录
索引

表达

1. 非形式化的需求规约：
   • 以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。适用于规模比较小的、复杂程度不大高的小型软件项目，或在获取SRS（草案）时使用的
2. 半形式化的需求规约：
   • 以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约，一些有能力的组织针对大型复杂项目，在开发需求文档时往往使用系统化的需求获取、分析技术和工具
3. 形式化的需求规约：
   • 以一种基于良构数学概念的符号体系来编制需求规约，一般常伴有解释性注释的支持，主要针对质量（特别是安全性）要求比较高的软件产品/系统或其中某一部分

作用

• 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现
• 对于项目的其余大多数工作，需求规约是一个管理控制点
• 对于产品／系统的设计，需求规约是一个正式的、受控的起始点
• 需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档—— 初始测试计划和用户系统操作描述

结构化方法

结构化需求分析

基本术语

• 数据流：是数据的流动
• 加工：是数据的变换单元，
  • 即接受输入的数据，对其进行处理并产生输出；在使用中，一般给出标识且标识为动宾结构
• 数据存储：是数据的静态结构
• 数据源、数据潭：数据源是数据流的起点，数据潭是数据流的归宿地
  • 数据流和数据潭是系统之外的实体，可以是人、物或者其他软件系统

系统功能模型表示

需求分析的首要任务是建立系统功能模型

结构化分析方法给出一种能表达功能模型的工具，即数据流图，简称DFD图

• 是一种描述数据变换的图形化工具
• 是一种表达待建系统功能模型的工具

软件工程分析工具

工具名称	工具作用
HIPO图	总体设计的工具
N-S图	详细设计的工具
PAD图	详细设计的工具
DFD图	结构化分析方法的表达功能模型的工具

建模过程

自顶向下，功能分解（助记：建图、求精、字典、加工）

可采用结构化自然语言、判定表和判定树描述加工

结构化设计

主要任务：在需求分析的基础上，定义满足需求所需要的结构，即针对给定的问题，给出该问题的软件解决方案，确定定“怎么做”的问题

总体设计

基本任务：把系统的功能需求分配到一个特定软件体系结构中，建立系统的模块结构，只声明其作用或功能

Yourdon提出的模块结构图

HIPO图【层次图+输入/处理/输出图】

带编号的层次图（H图）

IPO图

其中：【有效的主记录-->更新主记录、有效的事务记录-->更新主记录】这个没在mermaid上画出来，画上去会导致图混乱

总体设计步骤

• 系统的DFD图
  • 变换型数据流图：具有较明显的输入部分和变换（或称主加工）部分之间的界面、变换部分和输出部分之间界面的DFD图
  • 事务型数据流图：数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列 （或称一个事务）中选出一个来执行。处理T称为事务中心，完成以下任务：
    • 接收输入数据
    • 分析并确定对应的事务
    • 选取与该事务对应的一条活动路径
    • 事务型数据流图所描述系统的数据处理模式为集中一发散式
• 初始的模块结构图【基于 高内聚低耦合 这一软件设计原理模块化】
• 最终的、可供详细设计使用的模块结构图

设计准备

复审并精化系统模型

确定边界

交换【确定输入、变换、输出这三部分之间的边界】
事务【确定事务处理中心】

第一级分解

系统模块结构图顶层和第一层的设计

第二级分解

自顶向下，逐步求精

交换【事务】设计的基本步骤

变换设计与事务设计的区别及联系

	区别（目的、组成、任务）	联系
变换设计	将变换型数据流图映射为模块结构图 组成：获取数据、变换数据（核心）和输出数据 设计一个主控模块来协调和控制其他模块，比较机械	以变换设计为主 事务设计为辅
事务设计	将事务型数据流图映射为模块结构图 事务中心需完成3个任务： 接收数据、分析并确定事务和选取活动路径

耦合

• 内容耦合：一个模块直接修改或操作另一个模块的数据。耦合程度最高，尽量避免使用
• 公共耦合：两个或两个以上的模块共同引用一个全局数据项
• 控制耦合：一个模块通过接口向另一个模块传递一个控制信号（如开关、标志），接收信号的模块根据信号值进行适当的动作
• 标记耦合：模块A通过接口向模块B和C传递一个公共参数，称模块B和C间存在一个标记耦合
• 数据耦合：模块之间通过参数来传递数据。耦合程度最低，存在普遍

内聚

• 偶然内聚：各成分之间不存在关系
• 逻辑内聚：各成分逻辑上相关
• 时间内聚：各成分因时间因素关联在一起
• 过程内聚：模块内部处理成分相关且必须以特定次序处理
• 通信内聚：模块的所有程序都操作或生成同一数据集
• 顺序内聚：一个成分的输出作为另一个成分的输入
• 功能内聚：模块对完成其功能而言是充分必要的（最理想的）

实现高内聚低耦合的启发式规则：

• 改进软件结构，提高模块独立性；
• 力求模块规模适中(不超过60行)
• 力求深度、宽度、扇出和扇入适中（扇出3或4）
  • 深度：控制的层数，粗略标志一个系统的规模和复杂程度
  • 宽度：同一个层次上模块总数的最大值（受扇出影响）
  • 扇入：表明有多少个上级模块直接调用它
  • 扇出：一个模块直接调用的下级模块数目
• 尽力使模块的作用域在其控制域之内
  • 控制域：模块本身以及所有直接或间接从属于它的模块集合
  • 作用域：受该模块内一个判定所影响的所有模块的集合
• 尽力降低模块接口的复杂度
• 力求模块功能可以预测

详细设计

• 目标：将总体设计阶段产生的系统高层结构映射为以这些术语所表达的低层结构，即系统的最终结构
• 任务：具体描述模块结构图中的每一个模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精确地定义了满足需求规约的结构
• 结构化程序设计方法：是一种基于结构的编程方法，采用顺序结构、选择结构以及重复结构进行编程，每一结构只允许一个入口和一个出口
• 工具：程序流程图（程序框图）、盒图(N-S图)、PAD图、类程序设计语言PDL

总结

面向对象方法 UML

UML术语表

表达客观事物的术语

8个术语：类与对象、接口、协作、用况、主动类、构件、制品、节点

类与对象

类与对象

• + Public 公共的
• - Private 私有的
• # Protected 受保护的
• ~ Package/Internal 包/内部的

接口

接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务

协作 & 用况 & 主动类 & 构件 & 制品 &节点

术语	说明
协作	是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容 交互各方之间的相互作用，提供了某种协作性行为
用况	是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察到的结果
主动类	是一种至少具有一个进程或线程的类
构件	是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现
制品	是系统中包含物理信息的、可替代的物理部件
节点	是运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源

表达关系的术语

4个术语： 关联、泛化、细化、依赖

关联

是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述

• 链是对象之间具有特定语义关系的抽象，实现之后的链通常称为对象之间的连接

术语	说明
关联名	用于描述关联的一定内涵
导航	对于一个给定的类目，可以找到与之关联的另一个类目
角色	是关联一端的类目对两一段的类目的一种呈现
可见性	+ # - ~
多重性	类中对象参与一个关联的数目
限定符	是一个关联的属性或属性表，这些属性的值将与该关联相关类的对象集做了一个划分
聚合	通过一个类是另一类的一部分这一性质，对关联集进行分类， 凡满足这一性质的关联，都称为一个聚合 表达的是一种“整体/部分”的关系。
组合	是聚合的一种特殊形式，如果在一个时间段内， 整体类的实例中至少包含一个部分类的实例，并且该整体类的实例负责创建 和消除部分类的实例，那么这样的聚合称为组合
关联类	一种具有关联和类特性的模型元素。一个关联类可以被看做一个关联但还有类的特性 或被看做一个类但有关联的特性。
约束	有序：表明类中实例是有序的 无重复对象：表明类中对象是没有重复的 有重复对象：表明类中对象是有重复的 有序集合：表明类中对象有序且重复 列表或序列：表明类中对象有序但可重复 只读：表明一旦一个链由于对象而被填加到所参与的关联中 即作为该关联的一个实例时，该链不能修改和删除

泛化

是一般性类目（称为超类或父类）和它的较为特殊性类目（称为子类）之间的一种关系

约束	说明
完整	表明已经在模型中给出了泛化中的所有子类，尽管在表达的图形中有所省略 但也不允许增加新的子类
不完整	表明在模型中没有给出泛化中的所有子类，因此可以增加新的子类
互斥	表明父类的对象最多允许该泛化中的一个子类作为它的类型
重叠	表明父类的对象可能具有该泛化中的多个子类作为它的类型

细化 & 依赖

术语	说明
细化	是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约
依赖	是一种使用关系，用于描述一个类目使用另一类目的信息和服务

表达组合信息的术语——包

为控制信息组织的复杂性，UML提供了组织信息的一种通用机制一包，支持形成一些可管理的部分。换言之，包可以作为“模块化”和“构件化”的一种机制

UML的模型表达格式

类图

类图是可视化地表达系统静态结构模型的工具，通常包含类、 接口、关联、泛化和依赖关系等

• 组合（实心菱形）
• 聚合（空心菱形）
• 依赖（虚线）

多重性表达	含义说明	举例
1	精确1个	每个借阅记录（Loan）必须属于 1个 读者（Member）
0..1	0个或1个	一个人可能 有或没有 驾照
* 或 0..*	零个或多个（任意数量）	一个图书馆可以有 任意数量的图书
1..*	至少1个，可以更多	一个班级必须有 至少1名学生，可以更多
2..5	2到5个之间	一个双人游戏房间必须有 2到5人

PlantUML类图代码 在线预览

@startuml
' 设置中文字体（可选）
skinparam defaultFontName SimSun
skinparam classAttributeIcon false

' 定义类
class Library {
    - name: String
    - address: String
    + addBook(book: Book): void
    + removeBook(book: Book): void
    + registerMember(m: Member): void
}

class Member {
    - memberId: String
    - name: String
    - phone: String
    + borrowBook(): Loan
    + returnBook(): void
}

class Loan {
    - loanDate: Date
    - dueDate: Date
    + borrow(): void
    + returnBook(): void
}

class Book {
    - isbn: String
    - title: String
    - author: String
    - status: String
    + getTitle(): String
    + setStatus(s: String): void
}

' 定义关系

' Library 与 Book 之间是组合关系：图书属于图书馆，图书馆销毁则图书也应被管理清除（强生命周期依赖）
Library "1" *-- "0..*" Book : contains >

' Library 与 Member 之间是聚合关系：读者可以独立存在，不是图书馆的组成部分
Library "1" o-- "0..*" Member : has >

' Member 与 Loan 之间是组合关系：借阅记录由读者创建，通常随读者删除而清除
Member "1" *-- "0..*" Loan : manages >

' Member 和 Book 之间是依赖关系：借书时需要使用 Book 对象
Member ..> Book : borrows >

' 可选：添加注释说明组合 vs 聚合
note right of Library::contains
    组合（Composition）：
    图书馆“拥有”图书，
    图书生命周期依赖于图书馆。
    若图书馆关闭，图书也被清空。
end note

note right of Library::has
    聚合（Aggregation）：
    读者注册到图书馆，
    但读者可独立存在。
end note

note right of Member::manages
    组合（Composition）：
    借阅记录完全属于读者，
    删除读者时应删除其所有借阅记录。
end note

@enduml

用况图

用况图是一种表达系统功能模型的图形化工具

一个用况图通常包含6个模型元素：主题、用况、参与者、关联、泛化、依赖

模型元素	说明
主题	是由一组用况所描述的一个类，通常是一个系统或子系统
参与者	表达了一组高内聚的角色，当用户与用况交互时，该用户扮演这组角色
用况	外延：，用况表达了参与者使用系统的一种方式 内涵：一个用况规约了系统可以执行的一个动作序列
关联	是一种参与关系，即参与者参与一个用况。用况之间的3种关系：泛化、扩展、包含
泛化	指用况A和用况B之间具有一般/特殊关系
依赖	包含：是指用况A的一个实例包含用况B所规约的行为 扩展：是指一个用况A的实例在特定的条件下可以由另一用况B所规约的行为予以扩展 并依据定义的扩展点位置，B的行为被插入到A的实例中

• 关联关系（实线箭头）
• 泛化关系（空心箭头）

作用

• 可以为系统建模，描述软件系统行为的功能结构
• 可以对业务建模，描述企业或组织的业务过程结构

状态图

是显示一个状态机的图，其中强调了从一个状态到另一状态的控制流

元素	图形表示	含义
初始状态	实心圆 ●	对象生命周期开始
最终状态	内黑圆圈 ◉	对象生命周期结束
状态	圆角矩形	对象在某一时刻的条件或状况
转换	带箭头的线	从一个状态到另一个状态的变化
事件	转换线上文字（如“支付成功”）	触发状态变化的动作或信号
监护条件	[条件]（本例未用）	条件满足才可转换，如 [金额>0]

PlantUML类图代码 在线预览

@startuml
' 设置中文字体（可选）
skinparam defaultFontName SimSun
skinparam state {
    BackgroundColor<<initial>> LightGreen
    BackgroundColor<<final>> LightGray
}

' 定义状态图标题
title 订单状态图 - UML State Diagram

' 定义所有状态（使用中文显示名 + 英文别名）
state "待支付" as pendingPayment
state "已支付" as paid
state "已发货" as shipped
state "已完成" as completed
state "已取消" as cancelled

' 初始状态 → 待支付
[*] --> pendingPayment : 提交订单

' 状态转换
pendingPayment --> paid : 支付成功
paid --> shipped : 发货
shipped --> completed : 确认收货

' 取消路径
pendingPayment --> cancelled : 取消订单
paid --> cancelled : 申请退款并批准

' 最终状态
completed --> [*]
cancelled --> [*]

' 添加注释说明
note right of pendingPayment
    订单已创建但未支付
end note

note right of paid
    款项已到账
end note

note right of shipped
    物流已发出
end note

@enduml

顺序图

是一种交互图，即由一组对象以及按时序组织的对象之间的关系组成，其中还包含这些对象之间所发送的消息

PlantUML类图代码 在线预览

@startuml
' 设置中文字体和兼容性
skinparam defaultFontName SimSun
skinparam sequence {
ArrowColor #003399
ActivationBackground LightBlue
ParticipantPadding 20
SpaceWidth 50
}

' 定义参与者（对象）
actor "顾客" as Customer
participant "购物车系统" as ShoppingCart
participant "订单系统" as OrderSystem
participant "库存系统" as InventorySystem
participant "支付网关" as PaymentGateway

' 标题
title 顺序图：顾客下单流程

' 交互消息
Customer -> ShoppingCart: 提交订单请求
activate ShoppingCart

ShoppingCart -> OrderSystem: 创建订单(商品列表)
activate OrderSystem

OrderSystem -> InventorySystem: 检查库存(商品ID)
activate InventorySystem

InventorySystem --> OrderSystem: 库存充足
deactivate InventorySystem

OrderSystem -> PaymentGateway: 发起支付(金额)
activate PaymentGateway

PaymentGateway --> OrderSystem: 支付成功
deactivate PaymentGateway

OrderSystem --> ShoppingCart: 订单创建成功
deactivate OrderSystem

ShoppingCart --> Customer: 下单成功，等待发货
deactivate ShoppingCart

' 可选：添加注释
note right of PaymentGateway
调用第三方支付平台\n如支付宝、微信
end note

note right of InventorySystem
检查商品是否可售\n数量是否足够
end note
@enduml

元素	图形表示	含义
对象	矩形框	参与交互的类或系统组件
生命线	垂直虚线	对象在时间上的存在
激活条	垂直矩形	对象正在执行操作
消息	水平箭头	对象间的通信
- 同步消息	实线 + 实心箭头	调用后等待返回
- 返回消息	虚线 + 空心箭头	返回结果
自关联消息	自己调用自己	如循环或内部处理

面向对象方法 Rup

RUP（Rational Unified Process 统一开发过程）的突出特点：以一种用况为驱动的、以体系结构为中心的迭代增量式开发

RUP的特点

以用况为驱动

指在系统的生存周期中，以用况作为基础，驱动系统有关人员对要建立系统的功能需求进行交流， 驱动系统分析、设计、实现和测试等活动

用况是分析、设计、实现和测试的基本输入，分析、设计、实现和测试的结果都可以跟踪到相应的情况

以体系结构为中心

指在系统的生存周期中，开发的任何阶段都要给出相关模型视角下有关体系结构的描述，作为构思、构造、管理和改善系统的主要制品

迭代、增量式开发

指通过开发活动的迭代，不断地产生相应的增量

在RUP中，规定了4个开发阶段：初始阶段、精化阶段、构造阶段和移交阶段

核心工作流

需求获取

工具：采用Use Case（用例）技术获取需求

目标：使用UML中的用况、参与者及依赖等术语抽象客观实际问题，形成系统的需求获取模型 —— 一种特定的系统/产品模型 ，并产生该模型视角下的体系结构描述。

RUP要做的工作

要做的工作	说明	产生的制品
1 列出候选的需求	从客(用)户、计划(开发)者的想法和意愿中搜取特征 形成特征表，特征是一个新的项及其简要描述	特征列表
2 理解系统语境	业务用况模型：用用况图表达 为精化业务用况模型中的每一个业务用况， 表达其的3个术语：工作人员、业务实体、工作单元	领域模型/业务模型
3 捕获功能需求	目标：创建系统的用况模型，以表达客户认可的 需求——系统必须满足的条件和能力， 作为客户和开发人员间的一种共识 用况模型：系统的一种概念模型，是对系统功能的抽象 包括系统参与者、系统用况以及它们之间的关系	用况模型
4 捕获非功能需求		补充需求 针对些特定需求的用况

需求分析

• 目标：在系统用况模型的基础上，创建系统分析模型及在该分析模型视角下的体系结构描述
• 分析模型：是系统的一种概念模型，解决系统用况模型中存在的二义性和不一致性等问题，以一种系统化的形式准确表达用户需求
  • 分析模型由分析系统定义，该分析系统包含一组具有层次结构的包，每个包中可包含一些分析类和用况细化[分析]
• 用况细化：一个协作。针对一个用况，其行为用多个分析类间相互作用来细化
• 分析包：一种控制信息组织复杂性的机制，提供分析制品的一种组织手段，形成可管理的部分
• 分析的主要活动：
  • 体系结构分析：通过标识分析包和分析类，建立分析模型和体系结构“骨架”，标识有关分析包和分析类的特定需求
  • 用况分析：
    • 标识那些在用况事件执行流中所需要的分析类和对象
    • 将用况的行为，分布到参与交互的各个分析对象
    • 捕获用况细化上的特定需求
  • 类的分析：
    • 标识并维护分析类的责任
    • 基于它们在用况细化中的角色，标识并维护分析类的属性和关系
    • 捕获分析类细化中的特殊需求
  • 包的分析：
    • 确保分析包含尽可能与其他包相对独立
    • 确保分析包实现了它的目标，即细化了某些领域类或用况
    • 描述依赖，以利于可以估计未来的变化

分析类	边界类	封装一些重要的通信接口和用户界面机制
	实体类	封装问题域中的一个重要现象
	控制类	封装一些重要的定序

设计

目标：定义满足系统/产品分析模型所规约需求的软件结构

• 设计类：对系统实现中一个类或类似构造的一个无缝抽象
• 用况细化[设计]：设计模型中的一个协作，使用设计类及其对象，描述一个特定用况是如何细化、执行的。表达协作的工具：类图、交互图和正文事件流等
• 设计子系统：包含设计类，用况细化，接口，及其他子系统，通过对其操作来显示功能
• 接口：
  • 用于规约由设计类和设计子系统提供的操作
  • 为设计类/设计子系统提供一种分离功能的手段
  • 一个接口的重要关联是细化

设计的主要活动

• 体系结构设计
  • 创建设计模型和部署模型，及其视角下的体系结构描述
• 用况的设计
  • 分析模型的用况细化[分析]是该活动的输入，对应输出用况细化[设计]
• 类的设计
  • 完成用况细化[设计]中每一类的角色设计，完成有关每一类的非功能需求设计
• 子系统设计
  • 确保子系统尽可能独立于其他子系统或其接口
  • 确保子系统提供正确接口
  • 确保子系统实现了目标，即给出该子系统提供的接口定义的操作的细化

分析模型	设计模型
概念模型，对系统的抽象，无实现细节	软件模型，对系统的抽象，无实现细节
可用于不同设计	特定于一个实现
用3个衍型类：控制类、实体类、边界类	用多个衍型类，依赖于实现语言
几乎非形式化	较形式化
开发费用少（相对于设计是1:5）	开发费用高（相对于分析是5:1）
结构层次少	结构层次多
动态的，很少关注定序	动态的，更多关注定序
概括地给出了系统设计，包括系统的体系结构	表明了系统设计，包括设计视角下的系统体系结构
软件生存周期中不能修改、增加等	软件生存周期中应维护
为构建系统包括创建设计模型 定义一个结构是一个基本输入	构建系统时，尽可能保留分析模型所定义结构

实现&测试

RUP实现的目标：

• 基于设计类和子系统生成构件
• 对构件进行单元测试、集成、连接
• 把可执行的构件映射到部署模型

RUP实现的活动

活动步骤	输入	执行者	输出
设计模型 部署模型 体系结构描述 [设计模型、部署模型角度]	实现体体系结构	体系结构设计者	构件[概述] 体系结构 描述 [实现模型、部署、模型角度]
补充需求 用况模型 设计模型 实现模型[当前建造]	集成系统	系统集成者	集成建造计划 实现模型[连续的建造]
集成建造计划 体系结构描述 [实现模型角度] 设计子系统[已设计] 接口[已设计]	实现子系统	构件工程师	实现子系统[建造完成] 接口[建造完成]
设计类[已设计] 接口[由设计类提供]	实现类	构件工程师	构件[完成]
构件[完成]、接口	完成单元测试	构件工程师	构件[已完成单元测试]

软件测试

测试目标&过程

软件评估：静态评估（评审、走查和形式化证明）、动态评估 (软件测试)

测试目标：首要目标：预防错误（几乎不可实现），第二目标：发现错误

No.1

软件测试和软件调试无区别

No.2

测试为表明软件能正常工作

No.3

测试为表明软件不能正常工作

No.4

测试仅为了将已察觉的错误风险减少到可接受的程度

No.5

测试不仅是一种行为，而是一种理念，即测试是产生低风险软件的一种训练

软件测试所经历的阶段

标准概念：使用人工或自动手段，运行或测定某个系统的过程，目的是检验它是否满足规定的需求，清楚了解预期结果与实际结果间的差异

软件测试（Test）	软件调试（Debug）
从侧面证明程序员的失败	为证明程序员的正确。
从已知条件开始，使用预先定义的程序且有预知结果 不可预见的仅是程序是否通过测试	以不可知的内部条件开始 除统计性 调试外，结果不可预见
有计划、要进行测试设计	不受时间约束
一个发现错误、改正错误、重新调试的过	一个推理过程
执行有规程	执行要求程序要进行必要推理
由独立的组在不了解软件设计条件下完成	必须由了解详细设计的程序员完成
多数测试的执行和设计可由工具支持	程序员能利用的工具主要是调试器

软件测试是一个有程序的过程，包括测试设计、测试执行、测试结果比较等

软件测试技术

路径测试技术

• 用控制流程图表达被测程序模型，揭示程序的控制结构
  • 控制流程图：表示程序控制结构的图形化工具
• 合理选择一组穿过程序的路径，达到某种测试度量

• 过程块：没被判定和（或）被节点分开的一组程序语句
• 判定：一个程序点，此处控制流出现分叉
• 节点：一个程序点，此处控制流进行汇合
• 链：判定、节点、过程块之间一种具有特定语义的关系
• 路径：一个有程序入口和出口的链的集合
• 路径命名方式：用相关的链命名

	概念	特点
语句覆盖	至少执行程序中所有语句一次	度量最低
路径覆盖	执行所有可能穿过程序控制流程的路径	度量最强，不可实现
分支覆盖	确保每个判断的“真”和“假”结果都至少被执行一次
条件覆盖	确保每个布尔子条件（如 A > 0、B == 1） 都取过 true 和 false
条件组合覆盖	覆盖所有子条件的可能组合（如两个条件有 2²=4 种组合） 检测条件之间的相互影响

语句覆盖 < 分支 < 条件 < 条件组合 < 路径

	取值	说明
语句覆盖	x=85,y=85 x=95,y=80 x=80,y=95	覆盖操作一、二 覆盖操作一、三 覆盖操作一、四
路径覆盖	x=85,y=85 x=95,y=80 x=80,y=95 x=70,y=70	走操作二（路径） 走操作三 走操作四 什么都不做
分支覆盖	x=85,y=85 x=95,y=80 x=80,y=95 x=70,y=70	真 - - 假 真 - 假 假 真 假 假 假
条件覆盖	x=85,y=85 x=95,y=70 x=70,y=95	A真,B真,C假,D真,E真,F假 A真,B假,C真,D假,E真,F假 A假,B真,C假,D真,E假,F真
条件组合覆盖	x=85,y=85 x=85,y=75 x=75,y=85 x=75,y=75（覆盖C1）	真,真 真,假 假,真 假,假

基于事务流的测试技术

• 事务：指从系统用户角度出发所见到的个工作单元，由一系列操作组成
• 事务流程图：一种表达被测软件模型的工具

其他功能测试技术简述

等价类划分

• 等价类：把软件所有可能输入数据分成若干部分，一个部分中各数据发现软件错误的概率一样
• 有效等价类：合理、有意义的输入数据集合
• 无效等价类：不合理、无意义的输入数据集合
• 等价类划分：从等价类中选取数据作为测试用例进行软件测试

情况	划分原则
输入条件规定了输入数据取值范围	1个有效等价类、2个无效等价类
输入条件规定了输入数据的个数	1个有效等价类、2个无效等价类
输入条件规定了输入数据的一组可能取值	每一个输入值确定1个有效等价类 针对这组值确定1个无效等价类
输入条件是一个布尔量	1个有效等价类、1个无效等价类
输入条件规定了必须符合的条件	1个有效等价类、1个无效等价类
已划分的某一等价类中各元素在程序中的处理方式不同	将此等价类进一步划分为更小的等价类

边界值分析

使用等于、小于或大于边界值的数据对软件进行测试，发现错误的概率较大。故在设计测试用例时应选择一些边界值

情况	测试数据
输入条件规定了输入值的范围	等于边界值的数据，刚刚超过边界值的数据
输入条件规定了值的个数	最大个数、最小个数、比最大个数多1、比最小个数少1的数
输入域或输出域是有序集合	选取集合的第1个元素、典型元素、最后1个元素
程序中使用了内部数据结构	选择此内部数据结构边界上的值

黑盒测试

• 概念：将被测软件看作盒子，只通过外部输入、输出发现软件错误，完全不考虑稠序内部结构
• 别称：功能测试技术
• 典型：事务处理流程技术、状态测试技术、定义域测试技术
• 包括：事务流测试、等价类划分、边界值分析等
• 依据：软件行为的描述

测试步骤

单元测试

• 关注：每个独立的模块
• 任务：检验软件设计的最小单元模块
• 指导：详细设计文档
• 技术：白盒测试技术

测试中，模块不是独立程序，须为每个模块单元测试开发驱动模块和承接模块

• 驱动模块：模拟“主程序”接受测试用例的数据，将这些数据传送给要测试的模块并打印结果
• 承接模块：代替被测模块的下属模块，打印入口检查信息，并将控制返回到它的上级模块

集成测试

• 任务：关注接口有关错误，发现与接口有关的错误，将经过单元测试的模块构成一个满足设计要求的软件结构
• 驱动模块：主控模块，设计承接模块替代其直接的下属模块，按选取的测试方式（先深度/先宽度），在组合模块时进行测试

有效性测试

• 技术：黑盒测试技术
• 验证：软件需求的可追溯性
• 任务：关注检验是否符合用户的文档
• 目标：发现软件实现的功能与需求规格说明书不一致的错误

系统测试

• 关注检验系统中所有元素（包括硬件信息等）间的协作是否合适，整个系统的性能、功能是否达到要求
• 验证将软件融于更大系统时整个系统的有效性

软件生命周期过程与管理

概述

• 软件生存周期：软件产品/系统的一系列相关活动的全周期，从形成概念开始，历经开发、交付使用、在使用中不断修订和演化，直到最后被淘汰，让位于新的软件产品
• 软件工程标准的基础文件：《ISO/IEC软件生存周期过程12207一1995》
• 软件生存周期过程的3个过程：
  • 基本过程（获取、供应、开发、运行、维护）
  • 支持过程（文档、配置管理、质量保证、验证、确认、联合评审、审计、问题解决）
  • 组织过程（管理、基础设施、培训、改进）

过程描述

	验证	确认
定义	证实产品是否正确反映规约的需求	证实使用的软件是否满足需求
作用	证实是否正确的反映了所规约的需求	证实所期望使用的软件工作产品是否满足其需求
区别	与该产品所要求的特征进行比较	反映特定期望使用的特殊需求

应用说明

软件生存周期模型

瀑布模型

• 概念：将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品
• 作用：支持结构化软件开发、控制软件开发的复杂性、促进软件开发工程化
• 适用：需求已被很好的理解，且开发组织非常熟悉为实现这一模型所需要的过程

瀑布模型各开发阶段的活动

增量模型

• 概念：指需求可以分组，形成一个个的增量，并可形成一个结构，即该模型有一个前提，需求可结构化，在此条件下，对每一增量实施 瀑布式开发
• 适用：“技术驱动”的软件产品开发，常被工业界所采用
• 优点：
  • 第一个可交付版本需时间和成本较少
  • 减少用户需求的变更
  • 增量投资
• 缺点：
  • 初始增量可能会造成后来增量的不稳定
  • 一些增量就可能需要重新开发
  • 增大管理成本

增量模型示意图

演化模型

• 类型：迭代、增量式开发模型
• 概念
  • 基础：用户提出待开发系统的核心需求
  • 过程：
    • 根据需求，开发一个核心系统并投入运行，以便用户能够有效提出反馈
    • 软件开发人员根据用户反馈
    • 实施开发的迭代过程
• 选代：由需求、设计、编码、测试、集成组成
• 增量：通过增加或修正，产生软件产品的增量，最终完成软件产品的开发
• 适用：事先不能完整定义需求的软件

增量模型示意图

螺旋模型

• 既念
  • 在瀑布模型和演化模型的基础上，加入两者忽略的风险分析
  • 沿着螺旋线，经历制定计划，风险分析，实施工程，客户评估这4个方面的活动
  • 自内向外每旋转一圈便产生一个更为完善的新版本
• 适用：项目的开发风险很大或客户不能确定系统需求

螺旋模型示意图

喷泉模型

• 特征：迭代、无间隙
• 意义：说明了软件活动需要多次重复；活动之间没有明显的间隙
• 适用：面向对象技术的软件开发

喷泉模型示意图

过程规划与管理

过程管理包括过程建立、过程评估和过程改进

过程的建立

No.1

标识开发项目可用的SLCM

No.2

标识那些会影响SLCM选择的属性

No.3

标识为选择SLCM所需要的任何约束

No.4

评估所选择的SLCM

No.5

选择最能满足项目属性和约束的SLCM

选择软件生存周期模型（SLCM）的步骤

关于软件生存周期过程的监控

• 软件生存周期过程——回答软件开发需要做哪些工作
• 软件生存周期模型——回答软件开发活动或任务如何组织
• 软件项目过程管理——回答软件过程如何管理
  • 软件生存周期过程是软件生存周期模型和软件项目过程管理的基础
  • 软件生存周期模型为软件项目过程管理提供支持

集成化能力成熟度模型 CMMI

背景与原理

集成化能力成熟度模型 Capability Maturity Model Integration for Development

CMMI提出所基于的基本思想

• CMMI模型基于过程途径思想，把软件质量的3个支撑点：受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统产品
• CMMI紧紧围绕开发、维护和运行，把经过证明的最佳实践放在一个结构中
• 该结构有助于指导组织确定其过程的改善优先次序；有助于指导这些改善的实施，以提高其过程能力和成熟度，还支持 其他领域能力成熟度模型的开发

CMMI的模型部件

CMMI的主要模型部件

CMMI等级

能力等级

• 过程能力：是指遵循一个过程可达到的预期结果的程度。
• 能力等级：一种过程改善路径，该路径可使组织针对单一过程域不断改善该过程域，即指在单一过程域中已达到的过程改善。 能力等级是为了管理，对过程改善程度所设定的几个“台阶”
• CMMI有6个共用目标，用于表征过程制度化的程度，能力等级1~5分别对应共用目标1～5的过程，代表着过程制度化程度的提高。故共用目标编号越小，制度化程度越低。

等级	说明
0级	未完成级
1级	已执行级
2级	已管理级
3级	已定义级
4级	已定量管理级
5级	持续优化级

组织成熟度等级

• 成熟度等级：一种过程改善路径，该路径可使组织通过关注一组过程域不断改善一组相关过程域；意在改进组织的整体性能
• 成熟度等级的组成：由预先定义的一组过程域集及其相关的一些专用实践和共用实践。能力等级和成熟度等级 可用于评定活动、估算，作为过程评估的结果

等级	说明
1级	初始级
2级	已管理级
3级	已定义级
4级	已定量管理级
5级	持续优化级

过程域举例

• 项目规划过程域：建立并维护项目活动计划的定义
• 需求开发过程域：生成并分析客户、产品和产品部件需求

---

题型	个数	分值	总分
单选	15	2	30
填空	20	1	20
简答	6	5	30
综合应用	2	10	20