软件工程

更新: 4/10/2025   字数: 0 字   时长: 0 分钟

软件开发模型（⭐⭐⭐⭐）

原型模型【快速原型】

适用于需求不明确的场景。（用于需求阶段，作用是展示及获取需求）

两个阶段：

1. 原型开发阶段
2. 目标软件开发阶段

原型相关的模型：

演化模型

主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得新版本，重复这一过程，直到演化成最终的软件产品。

优点：任何功能一经开发就能进入测试阶段，以便验证是否符合产品需求，可引导出高质量的产品要求。

缺点：如果不加控制让用户接触开发中尚未稳定的功能，可能对开发人员和用户产生负面影响，即用户可能频繁改需求。

瀑布模型

瀑布模型是将软件生存周期中的各个活动以线性顺序连接成若干阶段的模型，包括需求分析、设计、编码、测试与维护。

特点：严格区分阶段，每个阶段因果关系紧密相连（前一个阶段工作的输出结果，是下一个阶段工作的输入），每个阶段有对应的成果产物。

优点：

• 容易理解，有利于人员的组织管理
• 有利于软件开发方法和工具的研究

缺点：

• 软件需求完整性、正确性难以确定。
• 严格串行化，很长时间才能看见结果。
• 要求每个阶段一次性完全解决该阶段的工作，这不现实。

适用于需求明确的项目，一般表述为需求明确、或二次开发，或者对于数据处理类型的项目。

增量模型

融合了原型实现的迭代特征和瀑布模型的基本成分，核心功能往往最先完成，可以有多个可用版本的发布，在此基础上，每轮迭代会有新的增量发布，核心功能可以得到充分测试。强调每一个增量均发布一个可操作的产品。

螺旋模型

结合了瀑布模型和演化模型的优点，最主要的特点在于加入了风险分析。它是由制定计划、风险分析、实施工程、客户评估这一循环组成的，它最初从概念项目开始第一个螺旋。

V模型

强调测试贯穿项目始终，而不是集中在测试阶段。每个开发阶段完成后都有对应的测试阶段，测试计划提前。

• 瀑布模型的测试阶段是在设计和编码都按顺序完成之后才开始，而V模型在需求分析阶段就开始了系统测试计划和测试用例的准备工作，只不过系统测试的执行通常在编码完成之后。
• 瀑布模型的开发和测试是完全分离的，两者缺少紧密的联系。而V模型的开发和测试之间有明确的对应关系。

W模型

测试和开发并行进行

V模型强调测试活动与开发活动的阶段一一对应，而W模型强调测试活动与开发活动的并行性，测试人员在每个阶段都会参与开发活动，并提供反馈。

例如在需求分析阶段：

• V模型：开发团队完成需求规格说明书之后，测试团队开始制定系统测试计划和设计系统测试用例等准备工作。
• W模型：测试人员不仅参与需求分析，还会验证需求文档的完整性和一致性，并进行相应的测试设计。

构件组装模型

优点：易扩展、易重用、低成本、安排任务更灵活

缺点：构件设计要求经验丰富的架构师，设计不好的构件难以重用，强调重用可能牺牲其它指标（如性能），第三方构件质量难控制。

案例：方舱医院、乐高积木

基于构件的软件工程CBSE（⭐⭐）

CBSE体现了购买而不是重新构造的哲学。即插即用，以接口为核心。

构件模型要素

接口

构件通过接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数、异常等。

使用信息

为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。用户可以通过元数据找到构件提供的服务。构件模型的实现通常包括访问构件的元数据的特定方法。构件是通用实体，在部署时必须对构件进行配置来适应应用系统。

部署

构建模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。

CBSE构件特征

1. 可组装性：所有外部交互必须通过公开定义的接口进行。
2. 可部署性：构建总是二进制形式，能作为一个独立实体在平台上运行。
3. 文档化：用户根据文档来判断构件是否满足需求。
4. 独立性：可以在无其它特殊构件的情况下进行组装和部署。
5. 标准化：符合某种标准化的构件模型。

构件的组装

• 顺序组装：按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。
• 层次组装：被调用构件”提供“的接口必须和调用构件”请求“的接口兼容。
• 叠加组装：多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的接口。

提示

构件的组装一般都要借助胶水代码！

组装可能出现的不兼容问题：

1. 参数不兼容：接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。
2. 操作不兼容：提供接口和请求接口的操作名不同。
3. 操作不完备：一个构件提供的接口是另一个构件请求接口的一个子集，或者相反。

快速应用开发RAD（⭐⭐）

快速应用开发（Rapid Application Development, RAD）是瀑布模型的一个高速变种，是一种比传统生命周期快得多的开发方法，它强调极短的开发周期，通常使用基于构件（CBSD）的开发方法获得快速开发。

适用性：

• RAD对模块化要求比较高，如果某项功能不能被模块化，则其构件就会出问题。
• 如果高性能是一个指标，且必须通过调整结构使其适应系统构件才能获得，则RAD也有可能不能奏效。
• RAD要求开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致失败。
• RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。

统一过程UP（⭐⭐）

UP(Unified Process)是一个通用过程框架，可用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP基于构件，在为软件系统建模时，使用UML。

典型特点是用例驱动、以架构为中心、迭代和增量。统一过程把一个项目分为四个不同的阶段：

• 初始阶段：定义最终产品视图和业务模型；确定系统范围。
• 细化阶段：设计及确定系统架构；制定工作计划及资源要求。
• 构建阶段：开发剩余构件和应用程序功能，把这些构件组装为产品，并进行详细测试。
• 移交阶段：确保软件对最终用户是可用的，进行β测试，制作产品发布版本。

注意

每阶段结束都要经过技术评审，每经过4个阶段就会产生一版软件，每一轮迭代都要进行测试和集成。

敏捷方法（⭐⭐）

传统软件开发方法	敏捷方法
预设性的	适应性的
已开发过程为本	以人为本
整体分阶段	增量迭代，小步快跑
	适合小型项目

敏捷宣言

• 个体和交互胜过过程和工具
• 可工作的软件胜过大量的文档（实现和测试是核心）
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

主要方法

• 极限编程（eXtreme Programming, XP）：四大价值观，近螺旋式的开发方法。适用于小型或中型项目团队，并且需求模糊或需求多变。
• 水晶方法（Crystal）：提倡“机动性”的方法，拥有对不同类型项目非常有效的敏捷过程。
• 开放式源码：程序开发人员在地域上分布广泛（其它方法强调集中办公）。
• SCRUM: 明确定义了可重复的方法过程，侧重于项目管理。
• 特性驱动开发（Feature Driver Development, FDD）：认为有效的软件开发需要三个要素——人、过程、技术。定义了6种关键的项目角色——项目经理、首席架构设计师、开发经理、主程序员、程序员、领域专家。
• 自适应软件开发（Adaptive Software Development, ASD）：核心是三个非线性的、重叠的开发阶段——猜测、合作、学习。
• 动态系统开发方法（Dynamic Systems Development Menthod, DSDM）：倡导以业务为核心。
• 测试驱动开发（Test-Driver Development, TDD）

极限编程XP

4条价值观：

• 沟通：加强面对面沟通
• 简单：不过度设计
• 反馈：及时反馈
• 勇气：接受变更的勇气

12条过程实践规则：

• 简单设计
• 测试驱动：基本设计完成后不应该直接编码，而是开发一系列检测本次发布的单元测试。单元测试应当使用一个自动实施的框架，支持代码修改后即时的回归测试策略。
• 代码重构：包括设计技术重构和构建技术重构。
• 结对编程
• 持续集成
• 现场客户
• 发行小型化版本
• 系统隐喻
• 代码集体所有制
• 规范策略
• 规范代码
• 40小时工作制

SCRUM

SCRUM是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一。

三类角色：

• 产品负责人（Product Owner, PO）
• 敏捷教练（Scrum Master）
• 开发团队（Team）

逆向工程（⭐）

• 实现级：包括程序的抽象语法树、符号表、过程的设计表示。
• 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
• 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
• 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型。

相关概念的区别：

• 重构/重组：在同一抽象级别上转换系统描述形式。
• 设计恢复：指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
• 逆向工程：逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
• 正向工程：不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
• 再工程：是对已有系统的重新开发过程，产生系统的一个新版本，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

净室软件工程（⭐）

• 强调以合理的成本开发出高质量的软件。
• 理论基础主要是函数理论和抽样理论。
• 提倡开发者不需要单元测试（但还是需要传统的模块测试），而是进行正确性验证和统计质量控制。
• 因为高质量改进管理，降低风险及成本，满足用户需求，提供竞争优势。

技术手段：

• 统计过程控制下的增量式开发：控制迭代

• 基于函数的规范和设计：盒子结构

  定义3种抽象层次：行为视图（黑盒）=> 有限状态机视图（状态盒）=> 过程视图（明盒）

• 正确性验证：净室工程的核心，它使软件质量有了极大提高。

• 统计测试和软件认证：使用统计学原理，总体太大时必须采用抽样方法。

缺点：

• 太理论化，正确性验证的步骤比较困难且耗时。
• 开发小组不进行传统的模块测试是不现实的。
• 脱胎于传统软件工程，不可避免带有传统软件工程的一些弊端。

需求工程（⭐⭐）

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。

考虑“做什么”，而不考虑“怎么做”，不关注开发平台和程序语言。

需求分类

需求的层次

• 领域需求：垂直领域，行业共性需求
• 业务需求：整体全局，通常是投资人、老板提出的，抽象层次最高
• 用户需求：用户视角
• 系统需求：
  • 功能需求【行为需求】：规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
  • 非功能需求【性能需求】：系统必须具备的属性或品质，可分为软件质量属性和其它非功能需求。
  • 设计约束【限制条件、补充规约】：如指定操作系统或指定数据库。

提示

业务需求=>用户需求=>系统需求，是不同的层次，分别是从目标到具体，从概念到细节。

质量功能展开QFD

QFD(Quality Function Deployment)是一种将用户需求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。

• 常规需求【基本需求】：用户认为系统应该做到的功能或性能，实现越多用户会越满意。
• 期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
• 兴奋需求【意外需求】：是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

需求获取

需求获取方法	特点
原型化方法	通过简易系统方式解决早期需求不确定的问题
头脑风暴法	一群人围绕新业务发散思维，不断产生新的观点
用户访谈	1对1-3个有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑
问卷调查	用户多，无法一一访谈，成本低
现场观摩	针对较为复杂的流程和操作
联合需求计划（JRP）	高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高
参加业务实践	有效地发现问题的本质和寻找解决问题的办法
情节串联板（原型前身）	一系列图片，通过这些图片来讲故事。类似PPT
抽样调查	基于数理统计，降低成本，快速获取

提示

获取用户想法：用户访谈 > 联合需求计划 > 问卷调查；但一般不会同时出现，如果涉及隐私问题，则选问卷调查。

需求分析

结构化需求分析SA

数据流图DFD

描述业务处理过程、系统边界内所包含的功能和系统中的数据流。

示例： 说明：0层图是对顶层图中【0在线教育平台系统】的细化。

案例技巧：

1. 数据流平衡原则：
   • 父图与子图之间的平衡：子图和父图中，同一外部实体的数据流在数量和名字上要相同。例如，顶层图中的学员有注册请求和课程安排两条数据流，则0层图中的学员也要一致。
   • 子图内部平衡
     • 黑洞：一个加工只有输入没有输出
     • 奇迹：一个加工只有输出没有输入
     • 灰洞：一个加工的输入数据流无法通过此加工产生输出流
2. 外部实体：
   • 人物角色：客户、管理员、主管、经理、老师、学生
   • 组织机构：银行、供应商
   • 外部系统：银行系统、工资系统
3. 数据存储：xx文件、表、库、清单、档案等
4. 加工名称：通常是“动词+名词”的结构，如生成报告、发出通知、批改作业、记录分数等，当然也有例外，如物流跟踪、用户管理等。

状态转换图STD

实体关系图ER

数据字典

数据字典是描述数据的信息集合，是对系统中使用的所有数据元素的定义和说明的集合。在结构化需求分析中，其主要作用是对数据流图中的各个元素做出详细的说明。

符号	含义	例子
=	等价于或定义	某高校内短号 = 8位数字
+	和	校内电话 = 3位区域数字 + 5位数字
[]	选择，分量之间用“|”间隔	区域数字 = [123 | 456 | 789]
m{}n	重复次数区间【m, n】	x=3{a}5，表示x由3个a，或4个a，或5个a组成
()	可选	校外手机号 = (+86) + 11位数字，+86是可选的

1. 数据元素【数据项】：不可再分的数据单位，简单理解就是数据库中的字段。
   • 数据项名称
   • 别名
   • 数据项类型
   • 长度
   • 取值范围
   • 默认值
   • 约束条件
   • 描述
2. 数据结构：反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
3. 数据流：数据结构在系统内传输的路径，对数据流图中的数据流进行说明。
   • 名称
   • 描述
   • 来源和去处
   • 传输的数据结构
4. 数据存储：系统中存储数据的地方，可以是数据库、文件、缓存等。数据存储包含了持久化的数据集合，支持数据的检索、更新、删除等操作。
   • 名称
   • 数据结构
   • 输入
   • 输出
   • 存储格式
5. 加工逻辑【处理过程】
   • 名称
   • 输入
   • 处理方法：描述加工操作的具体过程或算法。
   • 输出
6. 外部实体
   • 名称
   • 输入
   • 输出
   • 描述

• 案例参考1
• 参考2

面向对象需求分析OOA

面向对象基本概念

• 对象：属性（数据）+方法（操作）+对象ID
• 类
  • 实体类：实体类映射需求中的每个实体，保存需要存储在永久存储体中的信息。
  • 控制类：用于控制用例工作的类。
  • 边界类：用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交界处。
• 继承与泛化：复用机制，一般（共性，父类）和特殊（子类）的关系。父类是子类泛化而成（所谓泛化，即广泛化）
• 封装：隐藏对象的属性和实现细节，仅对外公开接口
• 多态：不同对象收到同样的消息产生不同的结果
• 重载：一个类可以有多个同名而参数类型不同的方法
• 接口：一种特殊的类，只有方法定义没有实现

UML

统一建模语言，与平台和开发语言无关。

三大要素：

构造块

• 事物：UML重要组成部分

  事物	说明
  结构事物	最静态的部分，包括：类、接口、协作、用例、活动类、构件、节点
  行为事物	代表时间和空间上的动作，包括：消息、动作次序、连接
  分组事物	看成是个盒子，包括：包、构件
  注释事物	UML模型的解释部分。描述、说明和标注模型的元素

• 关系：把事物紧密联系在一起

• 图：多个相互关联的事物的集合

规则

• 命名：为构造块命名
• 范围：给一个名字以特定含义的语境
• 可见性：怎样使用或看见名字
• 完整性：事物如何正确、一致地相互联系
• 执行：运行或模拟动态模型的含义是什么

公共机制

• 规格说明：事物语义的细节描述，它是模型真正的核心。
• 修饰：通过修饰来表达更多的信息。
• 公共分类：类与对象、接口与实现。
• 扩展机制：允许添加新的规则。
  • 约束：扩展构造块语义，允许添加新规则或修改现有规则
  • 构造型：扩展UML词汇，用于定义新的构造块
  • 标记值：扩展构造块特性，允许构造新的特殊信息来扩展事物的规格说明。

UML图

类图

描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态设计视图。

多重度：

多重度标记	说明
0	表示0个
1	表示1个
*	表示多个（也有表示0个或多个的情况）
0..*	表示0个或多个
0..1	表示0个或1个
1..*	表示1个或多个（至少1个）

示例：

• 1本书对应0或1条借阅记录（要么被借走了，要么没被借走）
• 1个书籍列表对应0或多本书

对象图

描述一组对象及它们之间的关系。对象图描述了类图中所建立的事物实例的静态快照。

构件图

描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图是类图的变体，用来表示系统的静态设计实现视图。

部署图

描述对运行时的处理节点及在其中生存的构件的配置。软硬件之间的映射。部署图给出了架构的静态部署视图，通常一个节点包含一个和多个部署图。

制品图

系统的物理结构。

包图

描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。包的图标类似一个带标签的文件夹，基本思想就是把共同工作的元素放到一个文件夹中。如：多个类或构件组成了一个子系统，就可以将它们放到一个包中。

组合结构图

描述结构化类（如构件或类）的内部结构，包括结构化类与系统其余部分的交互点。

用例图

描述一组用例、参与者以及它们之间的关系。

• 用户角度描述系统功能
• 参与者是外部触发因素
• 用例是功能单元

组成部分：

• 参与者：存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其它外部系统和设备等。
• 用例：系统中执行的一系列动作，这些动作将生成特定参与者可见的结果。用例表示系统所提供的服务。
• 通信关联（连线）：表示参与者和用例之间的关系，或用例和用例之间的关系（参与者使用某个用例A时，A会调用另一个用例B，然后B会返回结果给A，A再将结果返回给参与者）。如果不想表示对话的主动与被动（带箭头）关系，可以使用不带箭头的连线。

注意

信息流【数据流】并不是由通信关联来表示的，它是默认存在的，且是双向的。

活动图

将进程或其它计算结构展示为计算内部一步步的控制流和数据流，强调对象间的控制流程。类似流程图，但可并行。

泳道式活动图

提示

粗线之间的流程可以并行。

状态图

状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图，对接口、类或协作的行为建模尤为重要。

状态图是对类描述的补充，用于展现此类对象所具有的可能状态，以及某些事件发生时其状态转移情况。描述对象状态和事件之间的关系，强调对象基于事件反应的动态行为。

顺序图【序列图】

由一组对象或参与者以及它们之间可能发送的消息构成。描述对象之间传递消息的时间顺序。

提示

消息可以是信号、操作调用或类似C++中的RPC和Java中的RMI。

顺序图的组合片段：

• Loop【循环】：如果满足循环条件，则重复执行本框中的内容。
• Alt【条件分支】：满足条件1，则执行条件1对应的内容；满足条件2，则执行条件2对应的内容。
• Opt【可选分支】：如果条件满足，则执行框中内容，否则跳过不执行。

示例：

通信图【协作图】

描述对象与对象之间的协作关系，着重说明对象的消息传递，强调对象之间存在的消息收发关系，不专门突出这些消息的时间顺序。其建模结果用于获取对象的职责和接口。

提示

通信图强调的是时序，顺序图强调的是对象之间的组织结构（关系）。

定时图

用于展示交互过程中的真实时间信息，具体描述对象状态变化的时间点以及维持特定状态的时间段。

交互概览图

活动图和顺序图的混合图。

用例模型

从用户角度，采用用例图建立模型，分4个步骤：

1. 识别参与者
2. 合并需求获得用例
3. 细化用例描述
4. 调整用例模型（可选步骤）
   • 包含关系：从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例。
   • 扩展关系：一个用例明显混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
   • 泛化关系：当多个用例共同拥有一种类似的结构和行为时，可以将它们共性抽象为父用例，其它的用例作为泛化关系中的子用例。子用例继承父用例所有的结构、行为和关系。

提示

泛化与包含的区别关键在于是否存在父子关系。

包含关系：有点依赖的味道，A和B本质不一样，A包含B，所以使用A时会使用B。

扩展关系：一个事件可以有多种分支来实现。

示例1：细化用例描述——登入用例

示例2：用例关系

分析模型

分析模型是对软件系统需求的一种结构化、抽象化的描述，它聚焦于系统的功能、数据以及它们之间的相互关系，而不涉及具体的实现细节。从开发人员的角度出发，其核心作用在于帮助软件开发团队清晰地理解问题域，准确地把握系统的需求，确保开发的软件系统能够满足用户的期望。

领域模型【概念模型、域模型】：找到代表事物与概念的对象，即概念类。

以类图和对象图为主，交互图为辅，4个步骤：

1. 定义概念类：分析模型的主要任务是找到系统中的对象和类。

   1. 阅读和理解需求文档或用例描述
   2. 筛选出名词或名词短语，建立初始类清单（候选类）
   3. 将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类
   4. 舍弃明显无意义的类，原则如下：
      • 去除相同含义的
      • 去除不属于系统范围内的
      • 去除没有特定独立行为的
      • 去除含义解释不清楚的
      • 去除属于另一个类的属性或行为的
   5. 小组讨论不确定类别的类，直到将它们都合并或调整到其它两个类别，并进行相应的操作

2. 识别类之间的关系

   
   • 依赖关系：一个事物发生变化影响另一个事物。如：类A调用了类B的方法，则A依赖B
   • 关联关系：描述了一组链，链是对象之间的连接。
     • 聚合关系：整体与部分生命周期不同。如：汽车和轮子，汽车报废了，轮子还能再其它地方继续使用。
     • 组合关系：整体与部分生命周期相同。如：公司和部门，公司倒闭了，部分也跟着解散了。
   • 实现关系：接口与类之间的关系。
   • 泛化【继承】关系：特殊和一般的关系。

3. 为类添加职责

4. 建立交互图

案例参考

4+1视图

UML采用4+1视图来描述软件和软件开发过程。

视图	主要的UML图
用例视图	用例图
逻辑视图	类图、对象图
实现视图【开发视图】	包图、构件图
进程视图【过程视图】	活动图、顺序图、状态图、通信图
部署视图	部署图

总结

1. 面向对象分析方法适合开发大规模的、比较复杂的项目；而面向结构分析方法适合数据处理领域的问题。
2. 面向对象分析方法通常都会有用例模型和分析模型。
3. UML中事物的关系有：依赖、关联（聚合、组合）、泛化、实现；用例和类都是UML中的事物，所以其关系实际就是事物的关系，只不过具体到某个事物上有自己的特殊而已。用例中的包含和扩展实际就是UML事物关系中的依赖。
4. 面向对象的分析模型主要由顶层架构图、用例与用例图和领域概念模型构成。

需求定义

严格定义法

瀑布模型的思想：

• 所有需求都能够被预先定义
• 开发人员和用户之间能准确而清晰地交流
• 采用图形、文字可以充分体现最终系统

原型法

原型思想：

• 并非所有的需求都能在开发之前被准确地说明
• 项目参加者之间通常交流困难
• 需要实际的、可供用户参与的系统模型
• 有合适的系统开发环境
• 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法

需求验证

验收标准之一：用户签字确认

需求管理

需求状态跟踪

需求跟踪

变更控制

1. 识别出问题 => 问题分析和变更描述
2. 变更分析和成本计算
3. 变更实现 => 修改后的需求

需求变更控制流程步骤：

1. 明确问题
2. 书面申请
3. 判断变更需求类别
4. 评估变更影响
5. 判断变更的紧急级别
6. 沟通确认
7. 明确解决方案
8. 审批管理
9. 执行变更
10. 版本控制

系统工程建模（⭐）

MBSE（Model Based System Engineering），基于模型的系统工程。系统工程包含软件工程。

MBSE的三大支柱	软件工程
建模语言：沟通标准化，MBSE核心。典型代表：SysML、OPM	UML
建模思路：类似路线图。如：INCONSE面向对象系统工程法	面向对象开发
建模工具：Agilian、Modelio等	Visio、Rose

SysML

需求图

SysML中的需求关系：

• 包含（Include）：需求可以且只能包含其它需求。
• 跟踪（Trace）：对提供方元素（位于箭头端）的修改可能会导致对客户端元素（位于尾端）修改的需要。
• 继承（DeriveRept）：一个需求可以继承另一个需求的属性。
• 改善（Refine）：一个需求改进了另一个需求的满足程度。
• 满足（Satisfy）：一般是模块满足某种需求。
• 验证（Verify）：表示一个需求验证了另一个需求的正确性。
• 复制（Copy）：表示一个需求复制了另一个需求的特性。

提示

除"包含"之外，其它都是依赖关系。

系统分析与设计（⭐⭐）

软件系统建模

结构化建模方法

结构化建模方法是以过程为中心的技术，可用于分析一个现有系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图（DFD）。对于流程较为稳定的系统可考虑结构化建模方法。

信息工程建模方法【数据库建模方法】

信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型称为实体关系图（ERD）。该方法主要用于数据建模。

面向对象建模方法

面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统，是目前比较常用的建模方法。

人机界面设计

黄金三法则：

1. 置于用户控制之下
   • 以不强迫用户进入不必要的或不希望的动作方式来定义交互
   • 提供灵活的交互
   • 允许用户可以被中断或撤销
   • 当技能级别增加时可以使交互流水化并允许定制交互
   • 使用户隔离内部技术细节
   • 允许用户和出现在屏幕上的对象直接交互
2. 减少用户记忆负担
   • 减少对短期记忆的要求
   • 建立有意义的缺省
   • 定义直觉性的捷径
   • 界面的视觉布局应该基于真实世界的隐喻
   • 以不断进展的方式揭示信息
3. 保持界面一致性
   • 允许用户将当前任务放入有意义的语境
   • 在应用系列内保持一致性
   • 如果过去的交互模型已建立起用户期望，除非有万不得已的理由，否则不要改变它

结构化设计

根据模块独立性原则和系统结构原则，将DFD转换为系统结构图，用系统结构图来建立系统的物理模型，描述系统分层次的模块结构，以及模块之间的通信与控制关系。

设计步骤

1. 概要设计【外部设计】：将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图。
2. 详细设计【内部设计】：为每个具体任务选择适当的技术手段和处理方法。

提示

概要设计阶段涉及的图：模块结构图、层次图、HIPO图等。

详细设计阶段涉及的图：程序流程图、伪代码、盒图等。

设计原则

• 模块独立性原则（高内聚，低耦合）
• 扇入/扇出系统合理（多扇入，少扇出）
• 保持模块的大小适中
• 深度和宽度均不宜过高

提示

扇入：被其它模块调用；扇入越多，复用程度越高。

扇出：调用其它模块；扇出越多，复杂度越高。

高内聚低耦合

内聚程度（由高到低）	内聚类型	描述
高	功能内聚	完成一个单一功能，各个部分协同工作，缺一不可
	顺序内聚	处理元素相关，而且必须顺序执行
	通信内聚	所有处理元素集中在一个数据结构的区域上
	过程内聚	处理元素相关，而且必须按特定的次序执行
	时间内聚【瞬时内聚】	所包含的任务必须在同一时间间隔内执行
	逻辑内聚	完成逻辑上相关的一组任务
低	偶然内聚【巧合内聚】	完成一组没有关系或松散关系的任务

记忆：工（功能）序（顺序）通（通信）过（过程）是（时间）逻辑还是偶然。

耦合程度（由低到高）	耦合类型	描述
低	非直接耦合	两个模块之间没有直接联系，它们之间的联系完全是通过 主模块的控制和调用来实现的
	数据耦合	一组模块借助参数表传递简单数据
	标记耦合	一组模块通过参数表传递记录信息（数据结构）
	控制耦合	模块之间传递的信息中包含用于控制模块内部逻辑的信息
	外部耦合	一组模块都访问同一全局简单变量，而且不是通过参数表传递 该全局变量的信息
	公共耦合	多个模块都访问同一个公共数据环境
高	内容耦合	一个模块直接访问另一个模块的内部数据； 一个模块不通过正常入口转到另一个模块的内部； 两个模块有一部分程序代码重叠； 一个模块有多个入口

记忆：鼠（数据）标（标记）控制外（外部）公（公共）的容（内容）貌。

模块四要素

• 输入和输出：输入来源和输出去向都是同一个调用者，即一个模块从调用者那里取得输入，进行加工后再把输出返回给调用者。
• 处理功能：把输入转换成输出所做的工作。
• 内部数据：仅指供该模块自身引用的数据。
• 程序代码：用来实现模块功能的程序。

面向对象设计

基本过程

设计原则

• 单一职责原则：设计功能单一的类
• 开放封闭原则：对扩展开放，对修改封闭
• 里氏替换原则：子类可以替换父类
• 依赖倒置原则：要依赖于抽象而不是具体实现；针对接口编程，不要针对实现编程
• 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
• 合成复用原则：要尽量使用组合而不是继承关系达到重用目的
• 迪米特原则【最少知识原则】：一个对象应当对其它对象有尽可能少的了解

设计模式

23种设计模式，自己学吧！

软件测试（⭐⭐）

软件测试类型

提示

桌前检查、代码审查、代码走查都是做的静态分析！

静态分析：

• 控制流分析：是否存在没有使用的语句、无法达到的语句、调用并不存在的子程序。
• 数据流分析：引用未定义的变量，对之前未使用的变量再次赋值。
• 接口分析：模块之间接口的一致性，子程序和函数之间的接口一致性，函数形参与实参的数量、顺序、类型的一致性。
• 信息流分析：找出输入变量和输出变量之间的依赖关系。
• 表达式分析：括号不配对，数组引用越界，除数为零。

白盒测试【结构测试】

关注内部结构与逻辑，主要用于单元测试。

• 控制流测试【逻辑覆盖测试】：语句覆盖最弱，路径测试覆盖最强

  语句覆盖<判定覆盖<条件覆盖<判定/条件覆盖<条件组合覆盖<路径覆盖

• 数据流测试

• 程序变异测试【错误驱动测试】

黑盒测试【功能测试】

关注输入输出以及功能，主要用于集成测试、确认测试和系统测试阶段。

• 等价类划分：不同等价类，揭示不同问题；有效等价类/无效等价类。
• 边界值分析：如有1<=x<=10；则取x为0、1、10、11作为测试数据。
• 错误推测：依靠测试人员的经验和直觉。
• 判定表：最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。
• 因果图：根据输入条件和输出结果之间的因果关系来设计测试用例。

软件测试阶段

阶段性测试

• 单元测试：依据详细设计；模块测试，模块功能、性能、接口等。
• 集成测试：依据概要设计；模块间的接口。
• 系统测试：依据需求文档；在真实环境下，验证完整的软件配置项能否和系统正确连接。
• 确认测试：依据需求文档；验证软件与需求的一致性。

集成测试策略

• 一次性集成：风险高
• 增量式集成：测试全面
  • 自顶向下：需要桩模块（被测试模块所调用的模块）
  • 自底向上：需要驱动模块（调用了被测试模块的模块）
  • 混合式：需要桩模块和驱动模块

系统测试

功能测试：使用黑盒测试。

性能测试：

• 负载测试：各种工作负载下系统的性能
• 压力测试（测上限）：系统的瓶颈或不能接受的性能点
• 强度测试（测下限）：系统资源特别低的情况下运行
• 容量测试【并发测试】：同时在线的最大用户数
• 可靠性测试：MTTF之类的参数

其它测试

• AB测试：多版本同时使用，利于收集各版本的用户反馈，评估出最好版本。也算是一种网页优化方法。
• Web测试
  • Web系统测试：与其它系统测试测试内容基本相同，只是测试重点不同。
  • Web代码测试：包括源代码规则分析、链接测试、框架测试、表格测试、图形测试等。
• 链接测试
  1. 测试所有链接是否按指示的那样确实链接到该链接的页面。
  2. 测试所链接的页面是否存在
  3. 保证Web应用系统上没有孤立的页面
• 表单测试：验证服务器是否正确保存数据，后台运行的程序能否正确解决和使用这些数据。测试提交操作的完整性。
• 回归测试：测试软件变更之后，变更部分的正确性和对变更需求的符合性。

系统运行与软件维护（⭐）

遗留系统演化策略

对于继承

1. 需要对旧系统进行分析，得到其功能模型和数据模型。在开发新系统时，需要完全兼容旧系统的功能模型和数据模型。
2. 为保证业务的连续性，新旧系统必须并行运行一段时间，再逐渐切换到新系统上运行。

新旧系统转换策略

• 直接转换策略：旧系统直接停止，然后启动新系统。最省人力和费用，适用于不复杂的新系统或旧系统完全不能使用的场合。风险最大。
• 并行转换策略：新旧系统并行运行，新系统试运行一段时间后在淘汰旧系统。风险最小，但人力和费用消耗较大，转换周期长。
• 分段转换策略：两者结合，分期分批逐步转换，适用于较大的系统。

数据转换与迁移

影响可维护性的因素

• 可理解性：通过阅读源码和文档，了解软件功能和如何运行的容易程度。
• 可修改性：修改软件的难易程度。
• 可测试性：验证软件程序正确的难易程度。可测试性好的软件通常意味着软件设计简单，复杂性低。因为软件的复杂度越高，测试难易程度也就越大。
• 可靠性：软件越可靠，需要维护的概率就越低。
• 可移植性：软件从一个环境移植到一个新的环境下正常运行的难易程度。可移植性好的软件可以降低维护的概率。

软件维护分类

• 正确性维护（修Bug）：识别和纠正软件错误或缺陷，因为测试不可能发现所有错误
• 适应性维护（应变）：使应用软件适应环境变化（外部环境、数据环境）而进行的修改
• 完善性维护（新需求）：扩充功能和改善性能而进行的修改
• 预防性维护（针对未来）：为了适应未来的软硬件环境变化，应主动增加预防性的新功能，以使系统适应各类变化而不被淘汰。典型如：专用 改 通用。