软件测试最新软件工程_软件工程博客，软件测试基础开发入门

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

特点：

• 在前面增量的基础上开发后面的增量
• 每个增量的开发可用瀑布或快速原型模型
• 每个增量开发的顺序性和总体的迭代性相结合
• 有利于控制技术风险
  

螺旋模型

特点：

• 瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）
• 风险分析->发现、控制风险

一个螺旋式周期:

• 计划：确定目标，选择方案，选定完成目标的策略
• 风险分析：从风险角度分析该策略
• 开发：启动一个开发活动
• 评审：评价前一步的结果，计划下一轮的工作
  

迭代和瀑布的区别:

• 迭代和瀑布的最大的差别就在于风险的暴露时间上。
• 瀑布模型的特点（文档是主体），很多问题再最后才会暴露出来。
• 迭代模型的特点，根据风险列表选择要在迭代中开发新的增量内容，每次迭代完成时都会生成一个经过测试的可执行文件，可核实是否降低了目标风险。

构件集成模型

构件：

• 在某个领域中具有通用性，可以复用的软件部件
• 将可以复用的构件存储起来，形成构件库

特点：

• 面向对象
• 基于构件库
• 融合螺旋模型特征
• 支持软件开发的迭代方法
• 软件复用
  

(3) 形式化方法模型（基于程序变换和验证技术的软件开发）：转换模型，净室模型

转换模型

开发过程：

• 确定形式化需求规格说明书
• 进行自动的程序变换
• 针对形式化开发记录进行测试

特点：

• 形式化软件开发方法
• 形式化需求规格说明
• 变换技术
• 程序自动生成技术
• 确保正确
  

净室模型

净室思想：

• 在分析和设计阶段消除错误
• 在“洁净”状态下实现软件制作

形式化：

• 盒结构表示分析和设计
• 正确性验证

增量模型：

• ·把软件看成一系列的增量

(4) 软件过程模型的特点汇总

瀑布模型：

• 线性模型，每一阶段必须完成规定的文档，适合需求明确的中小型软件开发

快速原型：

• 用户介入早，通过迭代完善用户需求，原型废弃不用，适合需求模糊的小型软件开发

增量模型：

• 每次迭代完成一个增量，可用于OO开发。适合容易分块的大型软件开发

螺旋模型：

• 典型迭代模型，重视风险分析，可用于OO开发。适合具有不确定性大型软件开发

构件集成模型：

• 软件开发与构件开发平行进行，适用于领域工程、行业的中型软件开发

转换模型：

• 形式化的规格说明，自动的程序变换系统。属于理想化模型，尚无成熟工具支持

净室模型：

• 形式化的增量模型，在洁净状态下实现软件制作。适合开发团队熟悉形式化方法，中小型软件开发。

(5) 统一过程和敏捷过程

统一过程（RUP）

• 描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。
• 基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”

RUP将软件开发分为四个阶段：

• 初始阶段：该阶段的主要任务包括确定项目范围和边界，识别系统的关键用例，展示系统的候选架构，估计项目费用和时间，评估项目风险。其意图是建立项目的范围和版本，确定业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。

制品：构想文档、有关用例模型的调查、初始的业务用例、早期风险评估、显示阶段和迭代的项目计划等制品；

• 细化阶段：该阶段的主要任务包括分析系统问题领域，建立软件架构基础，淘汰最高风险元素。其意图是对问题域进行分析，建立系统的需求和架构，确定技术实现的可行性和系统架构的稳定性。提交结果包括系统架构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。

制品：补充需求分析、软件架构描述、可执行的架构原型

• 构建阶段：该阶段相对简单一些，其主要任务包括资源管理、控制和流程优化，开发剩余的构件，然后进行构件组装和测试等。其主要意图是增量式开发一个可以交付用户的软件产品。

制品：准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述。

• 提交(迁移)阶段：该阶段的主要任务包括进行β测试，制作发布版本，用户文档定稿，确认新系统，获取用户反馈，培训、调整产品使最终用户可以使用产品。其主要意图是将软件产品提交用户。

每个阶段又分为若干次迭代，每次迭代有一个核心工作流，都会经历需求、分析、设计、实现和测试等活动。

• 9个核心工作流，分为6个核心过程工作流和3个核心支持流。
• 核心过程工作流：商业建模、需求、分析和设计、实现、测试、部署
• 核心支持流：配置和变更管理、项目管理、环境

敏捷过程

• 一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”

敏捷过程价值观：

• 个人和交互胜过过程和工具
• 可以运行的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

极限过程

• 一种轻量级的、敏捷的软件开发方法
• 4个价值观：交流、简单、反馈、勇气
• 4个方面改善：加强交流、从简单做起、寻求反馈、用于实事求是
• 12个核心实践：完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度

(6) 软件可行性研究

目的：

• 研究项目是否可能实现和值得进行
• 回答Why to do

研究的内容：

• 经济可行性
• 运行可行性
• 技术可行性
• 法律可行性

可行性研究的步骤：

• 对当前系统进行调查和研究
• 弄清当前系统
• 导出新系统逻辑模型
• 导出新系统的解决方案
• 设计不同的解决方案
• 提出推荐的方案
• 本项目的开发价值
• 推荐这个方案的理由
• 编写可行性认证报告
• 系统概述
• 可行性分析
• 结论意见

(7) 软件风险分析

风险识别：

• 项目风险
• 技术风险
• 商业风险

风险预测：

• 风险发生的可能性
• 风险发生后的后果
• 风险的驾驭和监控

三、结构化分析与设计

1. 结构化分析与设计

• SP(结构化程序设计)->SD(结构化设计)->SA(结构化分析)
• 讨论传统软件工程的系统开发技术，重点放在基于瀑布模型的结构化分析与设计和模块设计上，但不涉及同为传统软件工程的快速原型开发等内容。

2. SA与SD的流程

• 结构化分析（工具：DFD数据流图、PSPEC加工策略）
  –>分析模型（分层DFD图）+SRS软件需求规格说明书）
• 结构化设计（工具：SC图）映射–>初始设计模型（初始SC图）
• 初始设计模型（初始SC图）优化–>最终设计模型（最终SC图）

3. 基本任务与指导思想

结构化分析：

• 建立分析模型
• 编写需求说明

结构化设计：

• 软件设计=总体设计+详细设计
• SC图需要分两步完成：初始SC图、最终SC图

细化与分解：

• 逐步细化，细化的本质就是分解

4. SA模型的组成与描述

SA模型的描述工具：

• DFD、PSPEC，这是早期SA模型的基本组成部分；
• CFD、CSPEC和STD是早期SA模型的扩展成分，适应实时软件的建模需要；
• ER图，适用于描述具有复杂数据结构的软件数据模型。
  
  备注：
• DFD数据流图、PSPEC加工规格说明/加工策略、STD状态转换图、DD数据字典、CSPEC控制规格说明

数据流图（DFD）

• 数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换，描述对数据流进行变换的功能和子功能
  

组成符号：

• 圆框代表加工
• 箭头代表数据的流向，数据名称总是标在箭头的边上
• 方框表示数据的源点和终点
• 双杠（或单杠）表示数据文件或数据库
• 文件与加工之间用带箭头的直线连接，单向表示只读或只写，双向表示又读又写

数据字典（DD）

• 数据字典的任务：对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。
• 对软件中的每个数据规定一个定义条目

①数据流：

数据流名： 发票
别 名： 购书发票
组 成： 学号+姓名+{书号+单价+数量+总价} +书费合计
备 注：

②数据文件
③数据项

数据流图与数据字典共同构成系统的逻辑模型

加工说明（PSPEC）

• 对数据流图中出现的每个加工/处理的功能描述
• 主要工具：结构化语言，判定树或判定表
  

5. SD模型的组成与描述

• 包含数据设计、接口设计、过程设计、体系结构设计
• 体系结构设计是用来确定软件结构的，其描述工具是结构图，简称SC图
• 过程设计主要指模块内部的详细设计
  

SC图组成符号和模块调用关系的标识:

• 矩形框表示模块，带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流
  简单调用、选择调用、循环调用:
  
  例：在模块A的箭头尾部标以一个菱形符号，表示模块A有条件地调用另一个模块B，当一个在调用箭头尾部标以一个弧形符号，表示模块A反复调用模块C和模块D。
  
• 程序的系统结构图
  

6. 结构化系统分析

结构化分析的基本步骤：

• 自顶向下对系统进行功能分解，画出分层DFD图
• 由后向前定义系统的数据和加工，编制DD和PSPEC
• 最终写出SRS

(1)画分层数据流图：（自顶向下，逐步细化）

好处：便于实现，便于使用

通常把整个系统当作一个大的加工标明系统的输入与输出，以及数据的源点与终点（统称为“外部项”）

• 顶层DFD：
  
• 第二层DFD：
  
• 第三层DFD：
  
• 采购子系统：
  

(2)确定数据定义与加工策略（从数据的终点开始）

• 数据定义DD
• 加工策略PSPEC
• 需求规格说明书SRS

(3)需求分析的复审

7. 结构化系统设计

SD概述

面向数据流设计和面向数据设计

• 面向数据流：数据流是考虑一切问题的出发点
• 面向数据：以数据结构作为分析与设计的基础

结构化设计的描述工具：SC图

从分析模型导出设计模型

• 分析模型：数据对象描述、数据流图DFD、数据字典DD、实体联系图ER图、加工规格说明书PSPEC、状态转换图STD、控制规格说明CSPEC
• 设计模型：过程设计、接口设计、体系设计、数据设计 由分析模型导出设计模型： 过程设计可以由PSPEC,CSPEC、STD导出；
• 接口设计可以由DFD导出； 体系结构设计可以由DFD导出； 数据设计可以由E-R、DD导出。

数据流图的类型——变换型、事务型

变换（transform）型结构:

• 传入路径
• 变换中心
• 传出路径
  

事务（transaction）型结构:

• 一条接受路径
• 一个事务中心
• 若干条动作路径
  

同时存在变换型结构和事务型结构：

SD方法

结构化软件设计方法——变换映射，事务映射

• 变换映射是软件系统结构设计的主要方法。一般一个大型的软件系统是变换型结构和事务型结构的混合结构。所以，我们通常利用以变换映射为主，事务映射为辅的方式进行软件结构设计。

变换映射:

• 划分DFD图的边界；
• 建立初始SC图的框架；
• 分解SC图的各个分支
  
  
  
  
• 深度：5层；宽度（广度）：7层；
• 注意：必须对一个模块的全部直接下属模块都设计完成之后，才能转向另一个模块的下层模块的设计；在设计下层模块时，应考虑模块的耦合和内聚问题；使用“黑箱”技术，先把这个模块的所有下层模块定义成“黑箱”，不考虑其内部结构和实现；一个模块的直接下属模块一般在五个左右，如果直接下属模块超过10个，可设立中间层次。

事务映射:

• 在DFD图上确定事务中心、接受部分（包括接受路径）和发送部分（包括全部动作路径)
• 画出SC图框架，把DFD图的3个部分分别映射为事务控制模块、接受模块和动作发送模块
• 分解和细化接受分支和发送分支，完成初始的SC图
  
  

扇入扇出

• 煎饼型不可取，应增加中间层减少扇出，实现塔型结构
• 设计良好的软件通常具有瓮型结构，两头小，中间打，在低层模块使用了较多高扇入的共享模块

优化结构设计的指导原则

对模块划分的指导原则

• 提高内聚，降低耦合
• 简化模块接口
• 少用全局性数据和控制型信息

保持高扇入/低扇出的原则

• 扇入高则上级模块多，能够增加模块的利用率
• 扇出低则表示下级模块少，可以减少模块调用和控制的复杂度

8. 模块设计

• 模块设计是传统软件工程的重要组成部分，其性质属于详细设计。

目的：

• 为SC图中的每个模块确定算法和数据结构，用选定的表达工具给出清晰的描述

主要任务：

• 编写软件的“模块设计说明书”

原则与方法：

• 清晰第一的设计风格
• 结构化的控制结构
• 仅用这三种控制结构（顺序、选择、循环）来构成程序
• 每个控制结构只应有一个入口和一个出口
• 逐步细化的实现方法

详细设计中常用的表达工具

• 流程图、N-S图、伪代码、PDL语言
  

四、面向对象与UML

1. 面向对象概述

(1) 类和对象的关系

对象：代表客观世界中实际或抽象的事物

• 客观世界是由各种对象组成的
• 数据以及在其上的操作的封装体

类：一组相似的对象的共性抽象

• 类是一组客观对象的抽象
• 实现抽象数据类型的工具

类与对象的关系

• 抽象与具体的关系
• 组成类的每个对象都是该类的实例
• 实例是类的具体事物
• 类是各个实例的综合抽象

(2) 面向对象的基本特征

• 抽象、封装、继承、多态

(3) 面向对象开发的优点

• 可复用性、可扩展性、可维护性

2. UML（统一建模语言）简介

• 通用的可视化的建模语言
• 目前在软件工程里主要用于系统分析与系统设计
• 软件生存周期：RUP（统一过程）
• 软件建模方式：可视化的语言
• 软件文档规范：文档由UML建模工具自动产生
• 软件人员分工：岗位界面逐渐趋向模糊

静态图：

• 类图：类以及类之间的相互关系
• 对象图：对象以及对象之间相互关系

实现图：

• 构件图：构件及其相互依赖关系
• 部署图：构件在各节点上的部署

交互图：

• 时序图：强调时间顺序的交互图
• 协作图：强调对象协作的交互图

行为图：

• 状态图：类所经历的各种状态
• 活动图：对工作流建模

用例图：

• 用例图：需求捕获，测试依据

(1) UML的模型元素

表示模型中的某个概念

• 类、对象、构件、用例、结点、接口、包、注释

表示模型元素之间的关系

• 关联、泛化、依赖、实现、聚集、组合

(2) UML的元模型结构

• 元元模型层、元模型层、模型层、用户模型层
  

(3) UML的组成

①图

静态图

• 用例图
• 静态图：类图、对象图
• 实现图：构件图、部署图

动态图

• 行为图：状态图、活动图
• 交互图：时序图、协作图

②视图

• 用例视图（用例图 [活动图] ）
  从用户角度看到的系统应有的外部功能
• 逻辑视图(静态:类图,对象图；动态:状态图,时序图,协作图,活动图)
  描述系统的静态结构和对象间的动态协作关系
• 进程视图（状态图、时序图、协作图、活动图、构件图、部署图）
  展示系统的动态行为及其并发性
• 构件视图（构件图）
  展示系统实现的结构和行为特征
• 部署视图（部署图）
  显示系统的实现环境和构件被部署到物理结构中的映射

③模型元素

④通用机制

(4) UML的特点

• 统一标准
• 面向对象
• 表达功能强大、可视化
• 独立于过程
• 易掌握、易用

(5) UML五类九种图的符号体系

3. UML主要内容

• 静态建模机制、动态建模机制

(1) 静态建模

静态建模包括

• 用例图、类图、对象图

用例模型

• 使用用例图表示
• 从最终用户的角度描述系统功能

类和对象模型

• 类图和对象图表示

1) 用例图与用例模型

用例图的组成符号

用例之间的关系
①扩展关系

• 根据指定的条件，一个用例中有可能加入另一个用例的动作；
  如果一个用例明显地混合了两种或者两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样可能会使描述更加清晰。扩展用例为基用例添加新的行为，可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
  是扩展关系的构造型，箭头指向基本用例。
  
  
  

②包含关系

• 一个用例的行为包含另一个用例的行为
  当可以从两个或两个以上的用例中提取公共行为时，应该使用包含的关系来表示它们。其中这个提取出来的公共用例成为抽象用例，而把原始用例成为基本用例或基础用例。
  是包含关系的构造型，箭头指向抽象用例。
  
  
  

包含关系和扩展关系的联系和区别：

• 联系：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
• 区别：扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。
  包含关系中基本用例的基本流执行时，包含用例一定会执行。

例：
现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立及更新病历。
要求根据现场情景，对医院病房监护系统进行需求分析， 建立系统的用例模型。

简单的需求分析说明
系统名称：医院病房监护系统
根据分析系统主要实现以下功能：
　　1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。
　　2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。
　　3、当病症信号异常时，系统自动更新病历并打印病情报告。
　　4、值班护士可以查看病情报告并进行打印。
　　5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。
　　6、系统定期自动更新病历。

2) 类图Class Diagram

类图表示类间关系:

关联关系（Association）

• 类之间存在的语义上的关系
• 普通关联、递归关联、多重关联等
  

二元关联:

• 表示为在两个类之间用一条直线连接，直线上可写上关联名
  
• 关联的两端可加上重数，表示该类有多少个对象可与对方的一个对象关联
  
• 允许一个类与自身关联
  

多元关联:

• 三个或三个以上的类之间可以互相关联
  
  

受限关联:

• 用于一对多或多对多的关联，限定符用来区分关联”多”端的对象集合，它指明了在关联“多”端的某个特殊对象
  

聚集关系（Aggregation）

• 特殊的关联：表示类之间具有整体与部分的关系
• 特征是“部分”对象可以是多个任意“整体”对象的一部分，“部分”可以参与到多个“整体”中，部分可以脱离整体。

组合关系（Composition）

• 特殊的聚集：整体强烈拥有部分
• 在组合中，“整体”强烈拥有“部分”，“部分”与“整体”共存。如果“整体”不存在了，“部分”也会随之消失。“整体”的重数必须是0或1，“部分”的重数可以是任意的。
  

泛化关系（Generalization）

• 又称继承
• 普通泛化，限制泛化

此处的一般元素可视作父类，特殊元素视作子类。

• 一般元素所具有的关联、属性和操作，特殊元素也都隐含性地拥有；
• 特殊元素应包含额外信息；
• 允许使用特殊元素实例的地方，也应能使用一般元素。
  

实现关系

• 实现关系将一个模型元素（如类）连接到另一个模型元素（如接口），后者是行为的规约，而不是结构，前者必须至少支持（通过集成或直接声明）后者的所有操作，可以认为前者是后者的实现。
  

依赖关系（Dependency）

• 对一个类/对象的修改会影响另一个类/对象

例如，某个类中使用另一个类的对象作为操作中的参数，一个类存取作为全局对象的另一个类的对象，或一个类的对象是另一个类的类操作中的局部变量等，都表示这两个类之间有依赖关系。
class Boss{
void do(Staff s){
s.do();
}
}

约束与派生:

• 约束与派生机制能应用于任何模型元素
• 用花括号括起放在模型元素旁边
• 典型的属性约束是该属性的取值范围
• 派生属性可由其它属性通过某种方式计算得到，通常在派生属性前面加一个“/”表示
• 关联关系可以被约束，也可以被派生
  

包图

• 描述系统的分层结构
  

3) 对象图Object Diagram

• 对象图是类图的实例。

(2) 动态建模

• 消息
  
• 状态图
  状态图描述对象的所有可能状态及事件发生时状态的转移条件
  
• 状态图之间发送消息
  
• 时序图（元素：对象、对象生命线、消息）
  时序图用来描述对象之间的动态交互，着重体现对象间消息传递的时间顺序。它以垂直轴表示时间，水平轴表示不同的对象。对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。对象间的通信在对象的生命线间通过消息符号来表示，消息的箭头指明消息的类型。
  
• 协作图（元素有对象、链接和消息流）
  协作图描述了对象间的动态协作关系，但它强调消息发生和接收的对象的结构组织（及连接关系）（协作对象之间的交互和链接）
  
  

(3) 物理架构建模

• 逻辑架构和物理架构
• 构件图：显示软件构件直接的依赖关系。一般来说，软件构件就是一个实际文件，可以是源代码文件、二进制代码文件和可执行文件。构件图可以用来表现编译、链接或执行时构件之间的依赖关系。
  
• 部署图：描述系统硬件的物理拓扑结构以及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含对的逻辑单元（对象、类）等。
  

五、需求工程与需求分析

1. 软件需求工程

软件需求的定义

一个软件系统必须遵循的条件或具备的能力

• 系统的外部行为——解决用户的问题
• 系统的内部特性——满足了文档的要求

软件需求三个层次

• 业务需求——从业务的角度评估
• 用户需求——从用户使用的角度描述软件必须完成的任务
• 功能需求——开发人员必须实现的功能

软件需求的特性

软件质量准则“FURPS”

• 功能性
• 可用性（易用性）
• 可靠性（平均无故障时间、精确度等）
• 性能（响应时间、吞吐量等）
• 可支持性（与系统相关的特性要求）
• 设计约束

软件需求工程

• 一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科。

2. 需求分析与建模

需求分析的步骤（迭代）：

• 需求获取、需求建模、需求描述（编写SRS）、需求验证
• 需求获取的目的是让开发人员通过各种方式充分和用户交流，全面、准确地了解系统需求；
• 建立需求模型是需求分析的核心，它通过各种图形及符合，可视化地从各个侧面描述系统需求；（结构化方法（包括数据流、数据字典、加工规格说明）和面向对象方法（面向对象方法包括用例模型、补充规约和术语表））
• 需求描述即编写需求规格说明书，它以各方共同认可的文档形式表述，是软件设计和系统验收的可靠依据；
• 需求验证用来检验以上各步的工作成果。

需求分析是一个迭代的过程

3. 需求获取的常用方法

常规的需求获取方法：

• 联合分析小组
• 用户代表、领域专家和系统分析员
• 客户访谈
• 充分准备，寻找共同语言
• 循序渐进、逐步逼近
• 问题分析与确认
• 多个来回

用快速原型法获取需求

• 利用各种分析技术和方法，生成一个简化的需求规格说明；
• 对需求规格说明进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；
• 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进；
• 将原型提交给用户评估并征求用户的修改意见；
• 重复上述过程，直到原型得到用户的认可。

4. 需求模型

需求模型概述

• 结构化需求模型
• 面向对象需求模型

面向对象的需求建模

• 画用例图
• 写用例规约
• 描述补充规约
• 编写术语表

结构化需求模型

• 该模型主要由3部分组成，即：包括数据流图和加工规格说明的功能模型；主要由数据字典和E-R图等组成的数据模型；由状态转换图、控制流图和控制规格说明等组成的行为模型。

面向对象需求模型

• 面向对象需求模型由3个部分组成：用例模型、补充规约和术语表，其中用例模型又包括用例图和用例规约

用例建模

确定参与者

• 存在与系统外部、与系统交互的人、硬件、其他系统

确定用例

• 考察每个参与者与系统的交互和需要系统提供的服务

绘制和检查用例图

• 按UML标准画用例图
• 检查用例图

细化每个用例的用例规约

内容包括：

• 简要说明：简要介绍该用例的作用和目的
• 事件流:包括基本流和备选流,表示出所有可能的活动及流程
  基本流:指该用例最正常的一种场景
  备选流:用于描述用例执行过程中的异常或偶尔发生的情况。
  它和基本流合起来，能够覆盖该用例所有可能发生的场景。
  包含元素：
  1、起点：该备选流从事件流的那一步开始
  2、条件：在什么条件下会触发该备选流
  3、动作：系统在该备选流下会采取哪些动作
  4、恢复：该备选流结束之后，该用例应如何继续执行
• 特殊需求： 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统和开发工具等）
• 前置条件和后置条件
  前置条件是执行用例之前必须存在的系统状态，后置条件是用例执行完毕后系统可能处于的一组状态。

用例模型的检查

• 功能需求的完备性
• 模型是否易于理解
• 是否存在不一致性
• 避免二义性语义

5. 软件需求描述

软件需求规格说明书

• 引言
• 信息描述
• 功能描述
• 行为描述
• 质量保证
• 接口描述
• 其他

6. 需求管理

需求管理的流程

需求确认

• 需求评审
• 需求承诺

需求跟踪

需求变更控制

• 需求变更利弊
• 需求变更流程

六、 面向对象分析

1. 软件分析概述

软件需求和软件分析

• 软件需求：用户角度，注重软件外在表现
• 软件分析：开发者角度，注重软件内部逻辑结构

2. 面向对象软件分析

(1) OOA的主要任务

• 理解用户需求
• 进行分析，提取类和对象，并结合分析进行建模。其基本步骤是：标识类，定义属性和方法；刻画类的层次；表示对象以及对象与对象之间的关系；为对象的行为建模。这些步骤反复进行，直至完成建模。

(2) OOA的模型

• 处于OOA模型核心的是以用例模型为主体的需求模型，抽取和定义OOA模型的3种子模型：
• 类/对象模型，描述系统所涉及的全部类和对象，每一类/对象都可通过属性、操作和协作者来进一步描述；
• 对象-关系模型，描述对象之间的静态关系，同时定义了系统中对象间所有重要的信息路径，也可以具体到对象的属性、操作和协作者；
• 对象-行为模型，描述了系统的动态行为，即在特定的状态下对象间如何协作来响应外界的事件。
  

(3) OOA的优点

• ①同时加强了对问题域和软件系统的理解
• ②改进包括用户在内的与软件分析有关的各类人员之间的交流
• ③对需求的变化具有较强的适应性
• ④很好地支持软件复用
• ⑤确保从需求模型到设计模型的一致性

(4) 分析模型的特点

• 全面覆盖软件的功能需求
• 分析模型与软件的实现无关
• 分析模型的表述方法与所采用的分析技术有关

(5) OOA的共同特征

共同特征

• 类和类层次的表示
• 建立对象-关系模型
• 建立对象-行为模型

(6) OOA的建模步骤

• 需求理解
• 定义类和对象
• 标识对象的属性和操作
• 标识类的结构和层次
• 建立对象-关系模型
• 建立对象-行为模型
• 评审OOA模型
  

面向对象开发的全过程是OOA,OOD,OOP和OOT的迭代过程。

• 面向对象分析（OOA）是一种从问题空间中提取类和对象来进行分析的方法，用于建立一个与具体实现无关的面向对象分析模型；
• 面向对象设计（OOD）则从问题空间转移到解空间，在分析模型的基础上考虑实现细节，形成面向对象的设计模型；
• 面向对象编程（OOP）则用于将设计模型转换成实现模型，可获得源代码和相应的可执行代码；
• 面向对象测试（OOT）则通过运行可执行代码来检测程序存在的问题。

3. 面向对象分析建模

(1) 识别与确定分析类

边界类<>

• 用户界面
• 系统接口
• 硬件接口
• 负责和用户进行交互的界面即用户界面

控制类<>

• 封装用例所特有的控制行为
• 负责实体类和边界类之间的交互

实体类<>

• 系统存储的信息及其相关行为
• 主要负责数据和业务逻辑
  
  为每对参与者/用例确定一个边界类
  
  为每个用例设置一个控制类
  
  确定相关的各个实体（包括属性与方法）
  

(2) 建立对象-行为模型

时序图（以选课用例中创建课表事件流的时序图）

协作图（以选课用例为例创建课表事件流的协作图）

(3) 建立对象-关系模型

分析类的属性：

• 分析类本身具有的信息

分析类的关联：

• 通过关联可以找到其他分析类，链与关联的对应关系

分析类图：表现分析类及其关系

• 描述用例的分析类图称为参与类图（VOPC）
• 每个用例可对应一张完整的参与类图，参与类图可以显示类的实例之间的数量关系。
  
• 100个用例->100个VOPC类图（每个类图有3个类）->全类图（<=300）个类

分析类的合并：

• 每个分析类都代表一个明确定义的概念，具有不相重叠的职责。一个类可以参与不同数量的用例，因此就整个系统而言，需要合并分析类，把具有相似行为的类合并为一个。每当更新了一个类，就要更新或补充用例规约，必要时还有更新原始的需求。
  
  **控制类（很少合并）
  实体类（基本都合并）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1N1aWhpZGVPbWVsZXQ=,size_16,color_FFFFFF,t_70)
协作图（以选课用例为例创建课表事件流的协作图）

(3) 建立对象-关系模型

分析类的属性：

• 分析类本身具有的信息

分析类的关联：

• 通过关联可以找到其他分析类，链与关联的对应关系

分析类图：表现分析类及其关系

• 描述用例的分析类图称为参与类图（VOPC）
• 每个用例可对应一张完整的参与类图，参与类图可以显示类的实例之间的数量关系。
  
• 100个用例->100个VOPC类图（每个类图有3个类）->全类图（<=300）个类

分析类的合并：

• 每个分析类都代表一个明确定义的概念，具有不相重叠的职责。一个类可以参与不同数量的用例，因此就整个系统而言，需要合并分析类，把具有相似行为的类合并为一个。每当更新了一个类，就要更新或补充用例规约，必要时还有更新原始的需求。
  
  **控制类（很少合并）
  实体类（基本都合并）

[外链图片转存中…(img-fy7VLI7H-1715619679176)]
[外链图片转存中…(img-PFCDIL5e-1715619679177)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！