软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

典型表现：

• 开发成本和进度的估计常常很不准确

• 用户对已完成的软件系统不满意，闭门造车

• 软件质量（quality）不可靠

• 软件常常是不可维护的

• 软件产品供不应求

• 软件成本（cost）的比例逐年上升

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。

软件工程的目标是研制、开发与生产出具有良好软件质量(quality)和费用合算的(economical)产品

• 采用工程化方法和途径来开发与维护软件

• 应该开发和使用更好的软件工具

• 采取必要的管理措施

软件的生命周期是从提出软件产品开始，直到该软件产品被淘汰的全过程。是一个孕育、诞生、成长、成熟、衰亡的生存过程。

软件生存周期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护。

1. 瀑布模型

   • 特点

     • 阶段间具有顺序性和依赖性
     • 推迟实现的观点
     • 质量保证的观点（文档驱动）

   • 缺点

     • 模型缺乏灵活性，不容易应对快速变化的需求
     • 开发过程一般不能逆转，否则代价太大
     • 规格说明很难理解
     • 软件的实际情况必须到项目开发的后期客户才能看到（文档驱动的两面性）

2. 快速原型模型（演化模型）

   • 特点

     • 针对事先不能完整地定义需求
     • 针对用户地核心需求，开发核心系统
     • 根据用户的反馈，实施活动的迭代

   • 优点

     • 可以处理模糊需求
     • 开发者与用户可以充分沟通，系统对用户更友好
     • 降低系统失败风险
     • 降低总的开发费用，缩短开发时间

   • 缺点

     • 如果核心需求识别错误，可能导致原型系统不合要求
     • 资源规划和管理较为困难
     • 容易忽视原型环境与最终用户环境的差异

3. 增量模型

   • 优点

     • 每个阶段交付一个可用的产品
     • 减少一个全新产品给客户带来的心理上的影响
     • 分阶段地交付产品不需要大的资金支出
     • 需求经常变化，增量模型的灵活性使其具有更加优越的适用性

   • 缺点

     • 需要一个开放的结构，方便构件的加入
     • 由于一些模块必须在另一个模块之前完成，所以必须定义良好的接口

4. 螺旋模型（大规模软件项目）

   • 活动

     • 制定计划
     • 风险分析
     • 实施工程
     • 客户评估

   • 优点

     • 容易确定什么时候已经对某一阶段的产品充分测试完毕
     • 维护和开发之间没有什么本质上的差别

   • 缺点

     • 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识

5. 喷泉模型

   • 迭代：重复、演进
   • 无间隙：各阶段间无明显界限

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。

软件项目管理的根本目的是为了让软件项目，尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下，以预定成本按期、按质的完成软件，然后交付用户使用。

时间、质量和成本管理构成了三角形

• 时间约束：完成项目所需的时间以及时间进度安排。

• 成本约束：为完成项目而需要的各种资源所产生的成本费用，包括人力、物力、财力等。

• 范围约束：定义了项目要完成的工作内容和最终交付的产品特性、功能等。

进度是对执行的活动和里程碑制定的工作计划日期表

进度管理是为了确保项目按期完成所需要的过程

甘特图能很形象地描绘任务分解情况，以及每个子任务(作业)的开始时间和结束时间，因此是进度计划和进度管理的有力工具。

优点：直观简明和容易掌握、容易绘制

缺点：

• 不能显式地描绘各项作业彼此间的依赖关系
• 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象
• 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费

· 软件需求的概念和分类

· 数据流图

· 数据字典的概念

软件需求：用户解决问题或达到目标所需要的条件。系统或系统部件要满足合同、标准、规范或其他正式规定的文档所要具有的条件。反映上面两条的文档说明。

“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

希望通过需求分析

• 对开发进行指导

• 开发人员理解用户的要求

• 用户理解开发人员

• 测试部门有理可依

需求分析：确定系统需要实现的功能和性能，以及系统要求的运行环境。以一种清晰、简洁、一致且无二义性的方式，对一个系统各方面描述的一个集合，以文档形式表现。

类别：

• 功能需求
• 性能需求
• 可靠性和可用性需求
• 出错处理需求
• 接口需求
• 约束
• 逆向需求
• 将来可能提出的要求

数据流图

数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能（和子功能）。它可以用于信息域的分析，作为功能建模的基础。

顶层流图仅包含一个加工，它代表将被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。

建立数据流模型的基本步骤概括地说，就是自外向内、自顶向下、逐层细化、完善求精。

数据字典的作用，就是描述软件中的每个数据和加工的具体含义，以保持数据在系统中的一致性。数据字典对数据流图中出现的所有名字（数据流、加工、数据存储）进行定义

数据流条目

文件条目：列出数据存储的组成数据项及文件的组织方式

数据项条目：无论是独立的还是包含在数据流或文件中的数据项，一般都应在字典中设置相应的条目

加工条目

状态转换图（状态图）：描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果，系统将做哪些动作。

状态是任何可以被观察到的系统行为模式

在状态图中定义的状态主要有：初态、终态、中间状态

事件是某个特定时刻发生的事情，它引起系统做出动作或系统状态转变

状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向

· 模块独立性的概念、意义

· 模块独立性的两个度量标准：耦合、内聚

· 耦合、内聚的几种类型

模块化：将程序划分为若干个独立的模块，每个模块完成一个特定子功能，每个模块既是相对独立的，又是相互联系的，它们共同完成系统指定的各项功能

模块化的目的：降低软件的复杂性

信息隐藏：在设计和确定模块时，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。

模块独立性概括了把软件划分为模块时要遵守的准则，也是判断模块构造是不是合理的标准，同时也是模块化和抽象及信息隐藏概念的直接产物

坚持模块独立性，是获得良好设计的关键

希望这样设计软件结构，使得每个模块只完成系统要求的一个相对独立的特定子功能，并且和其他模块之间的关系很简单

模块本身的内聚、模块之间的耦合

内聚：从功能角度对模块内部各个成分之间的紧密程度的度量。即内聚是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量

• 偶然性内聚/巧合内聚：块内各组成成分在功能上是互不相关的
• 逻辑性内聚：这种模块把几种相关、相似功能组合在一起，每次被调用时，由传递给模块的参数来确定该模块应该完成哪一种功能
• 时间性内聚：如果一个模块所包含的任务必须在同一“时间”内完成
• 过程性内聚：当一个模块中包含的一组任务必须按照某一特定的次序执行时
• 通信性内聚：模块内部各个成分都使用同一种输入数据，或者产生同一个输出数据。它们靠公用数据而联系在一起
• 顺序性内聚/信息内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常一个处理元素的输出数据作为下一个处理元素的输入数据
• 功能性内聚：如果一个模块包括仅为完成某一具体任务所必需的所有成分，或者说模块中所有成分结合起来是为了完成一个具体的任务

耦合是对软件内部模块之间相互联系的紧密程度的度量

• 非直接耦合：若两个模块没有直接联系，它们之间的联系完全是通过主程序的控制和调用来实现的，便称这两个模块为非直接耦合，这样独立性最强。

• 数据耦合：两个模块之间仅通过参数表传递简单数据。即一个模块调用另一个模块，被调用模块的输入和输出都是简单的数据。

• 特征耦合：模块间通过参数表传递一个数据结构并且只使用其中的一部分

• 控制耦合：一个模块传送给另一个模块的参数中包含了控制信息，控制接收模块的执行逻辑。（用作控制信号的开关值或标志量flag）

• 外部耦合：若允许一组模块访问同一个全局变量，可称它们为外部耦合。

• 公共耦合：若允许一级模块访问同一个全局性数据结构，则称之为公共耦合。

• 内容耦合

  如果发生下列情形，两个模块之间就发生了内容耦合

  • 一个模块直接访问另一个模块的内部数据
  • 一个模块不通过正常入口转到另一模块内部
  • 两个模块有一部分程序代码重迭
  • 一个模块有多个入口

· 数据流图映射成软件结构图：变换型、事务型

1）变换流

信息沿输入通路进入系统，由外部形式变换成内部形式，进入系统的信息通过变换中心，经加工处理以后再沿输出通路变换成外部形式离开软件系统。当数据流图具有这些特征时，这种信息流就叫作变换流。

2）事务流

数据沿输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。这类数据流应该划为一类特殊的数据流，称为事务流。

· 过程设计工具：程序流程图、盒图（N-S图）、PAD图、判定表/树、PDL

程序流程图优点：

• 采用简单规范的符号，画法简单
• 结构清晰，逻辑性强
• 便于描述，容易理解

开始、结束：椭圆矩形

输入输出为平行四边形

判断：菱形

其他：矩阵

盒图（N-S图）：每个处理步骤用一个盒子表示。盒子可以嵌套。盒子只能从上头进入，从下头走出，除此之外别无其他出入口，所以盒图限制了随意的控制转移，保证了程序的良好结构

特点：

• 功能域(即一个特定控制结构的作用域)明确，可以从盒图上一眼就看出来。

• 不可能任意转移控制。

• 很容易确定局部和全程数据的作用域。

• 很容易表现嵌套关系，也可以表示模块的层次结构

PAD图（问题分析图）

优点

• 清晰的反映了程序的层次结构

• 支持逐步求精的设计方法

• 易读易写，使用方便

• 支持结构化程序设计

• 可自动生成程序

PDL

优点：

• 可以作为注释直接插在源程序中间。
• 可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作。
• 已经有自动处理PDL的程序存在，而且可以自动由PDL生成程序代码。

缺点：不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单。

软件测试

目的是希望以最低代价，以尽可能多地找出软件中潜在的各种错误和缺陷。

软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。

软件测试基本原则

1. 尽早、不断地进行测试
2. 每个测试用例都必须包含测试输入数据和对应地预期输出的描述
3. 在某一程序片段中发现的错误越多，则这个程序段所隐含的尚未发现错误的可能性越大
4. 完全测试程序是不肯的
5. 寄生虫特性：找到的软件缺陷越多，就说明软件缺陷越多
6. 杀虫剂怪事：软件测试越多，其对测试的免疫力越强的现象

是否执行程序：静态测试、动态测试

软件测试用例的设计方法：白盒测试、黑盒测试

1 静态测试

• 通过检查和评审软件而不是运行软件对软件进行测试的方法。静态测试可以手工进行，也可以借助软件工具自动进行

测试对象：各类文档、源代码等

特点：

• 不必动态的运行程序，也就不必进行测试用例的设计和结果判读等工作

• 静态测试可以由人工进行，充分发挥人的逻辑思维优势，行之有效

• 静态测试实施不需要特别条件，容易开展

• 人工进行：

  • 桌面检查：程序员阅读自己所编的程序。效率不高
  • 代码审查
  • 代码走查：提供若干测试用例（程序的输入数据和期望的输出结果），用头脑来执行程序
  • 技术评审

• 主要由软件工具自动进行的静态分析

• 广义理解，还包括软件需求分析和设计阶段的技术评审

内容：

• 需求定义的静态测试：测试对照条例
• 设计文档的静态测试
• 源代码的静态测试

2 动态测试

• 通过运行软件来检验软件的动态行为和运行结果的正确性
• 两个基本要素：被测试程序、测试数据（测试用例）
• 核心内容：生成测试用例、运行程序、验证程序的运行结果

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

单元测试时通常采用白盒测试，或白盒测试与黑盒测试相结合的方法，而在集成测试、确认测试或系统测试中大都采用黑盒测试

2.1 黑盒测试

功能性测试，基于规格说明的测试，数据驱动测试

是在已知软件产品具有何种功能的前提下，用来检验每个功能是否能够正常使用，需求是否满足的一个测试方法，在软件开发后期进行。

把程序看成是一个不能打开的黑盒子，在不考虑程序内部结构的情况下，测试人员用操作接口的方式进行测试，检查程序能否按照需求指定的功能接收输入数据产生正确的结果。黑盒测试方法是在程序接口上进行测试。

优点：

1. 比较简单，不需要了解程序内部的代码及实现

2. 与软件的内部实现无关，如果实现发生变化，黑盒测试用例仍然可用

3. 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题

4. 基于软件开发文档，所以用例设计可以与软件的实现同时进行

缺点：

1. 不能覆盖所有代码，覆盖率较低
2. 只能找到缺陷，难以查找错误的具体原因

2.1.1 等价类划分

• 等价类测试是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规约来设计测试用例

• 把程序的输入定义域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例

• 在分析程序的规约的基础上划分等价类，列出等价类表

可以把全部的输入数据划分成若干个等价类，在每一个等价类中取一个数据来进行测试

优点：能以较少的具有代表性的数据进行测试，而取得较好的测试效果

• 有效等价类：对于程序的规约来说，是合理的、有意义的输入数据所构成的集合。利用它可以检验程序是否实现了预期的功能和性能。在具体问题中，有效等价类可以有一个，也可以是多个

• 无效等价类：对于程序的规约来说，是不合理的、没有意义的输入数据所构成的集合。利用它可以检验程序对于无效数据的处理。对于具体的问题，无效等价类可以有一个，也可能有多个

划分等价类

• 覆盖

• 不相交

• 代表性

• 对每个输入或外部条件进行等价类划分，形成等价类表，为每一等价类规定一个唯一的编号

• 设计一测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖

• 设计一新测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖

2.1.2 边界值分析

（1）边界值分析

关注输入空间的边界，从中标识测试用例

原理：错误更可能出现在输入变量的极值附近。

关键假设：“单缺陷”假设，失效问题极少是由两个（或多个）缺陷的同时发生引起的

方法：仅让一个变量取极值，其他所有变量取正常值

在最小值、略高于最小值、正常值、略低于最大值、最大值处取输入变量值

• 对于一个n变量函数，让一个变量依次取min、min+、nom、max-、max各个极值，而其他所有变量取正常值。依次对每个变量都重复这个过程即可

• 对于一个关于n变量的函数，边界值分析会产生4n+1个不同的测试用例

（2）健壮性测试

除了对变量5个边界值进行分析之外，还要进一步考察略大于最大值（max+）的值，以及略小于最小值（min-）的值

对于健壮性测试，最重要的不是输入，而是预期的输出

最主要的价值在于把注意力集中在系统对异常情况的处理上

一个变量个数为n的函数的健壮性测试会产生6n+1测试用例

（3）最坏情况测试

对每一个变量，分别构造包含min、min+、nom、max-、max这5个基本值的取值集合，然后通过计算这些集合的笛卡尔积，来构造测试用例

对一个n变量函数来说，最坏情况测试将会构造出5ⁿ个测试用例

（4）健壮最坏情况测试

对每一个变量，分别构造包含min、min+、nom、max-、max，以及max+（略大于最大值）和min-（略小于最小值）这样7个元素的集合，然后计算这些集合的笛卡尔积，以生成测试用例

对n个变量的函数来说，健壮最坏情况测试会产生7ⁿ个测试用例

错误猜测法：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些内容选择测试用例。更多地依赖人们的先验知识。

因果图：从程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变）之间的关系，通过将因果图转换为判定表，最后为判定表中的每一列设计一个测试用例。

2.2 白盒测试

结构性测试，基于程序的测试，逻辑驱动测试

前提：知道软件产品内部工作过程。

目标：通过测试来检测软件产品内部动作是否按照规格说明书的规定正常进行。

重点：从程序的控制结构导出测试用例。按照软件内部的结构测试程序，软件中的每条通路是否都能按预定要求正确工作。

在软件开发早期执行。

2.2.1 逻辑覆盖

• 语句覆盖：设计若干测试用例，运行被测程序，使程序中每个可执行语句至少执行一次。可以很直观地从源代码得到测试用例，无须细分每条判定表达式。语句覆盖是最弱的逻辑覆盖。对程序的逻辑覆盖很少，只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值时的情况。

• 判定覆盖（分支覆盖）：设计若干测试用例，运行被测程序，使得程序中每个判定的取真分支和取假分支至少经历一次，即判定真假值均曾被满足。

• 条件覆盖：设计若干测试用例，执行被测程序以后要使每个判定中每个条件的可能取值至少满足一次。条件覆盖不一定包含判定覆盖，条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

• 判定 - 条件覆盖：设计足够的测试用例，使得判定条件中的所有条件可能取值至少执行一次，同时，所有判定的可能结果至少执行一次。未考虑条件的组合情况。

• 条件组合覆盖：设计足够的测试用例，使得每个判定中所有可能的条件取值组合至少执行一次。

• 路径覆盖：设计所有的测试用例，来覆盖程序中的所有可能的执行路径。需要设计大量、复杂的测试用例，使得工作量呈指数级增长，不见得把所有的条件组合都覆盖。

2.2.2 基路径测试

如果可以把程序看做是一种向量空间，则这种空间的基就是要测试的非常有意义的元素集合。如果基没有问题，则可以期望能够用基表达的一切都是没有问题的。

基路径测试法是在程序控制流图的基础上，通过分析控制构造的圈复杂度，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行路径至少执行一次。

McCabe圈复杂度

圈复杂度：是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目。圈复杂度对应着独立路径数目。

独立路径：必须包含一条在定义之前不曾用到的边（即至少经过一条以前未走过的边）

1. V(G) = e – n + 2p

   • e：控制流图的边数
   • n：控制流图的节点数
   • P：图的连通区域数（图的连通区域是相连节点的最大集合）。一般条件下，控制流图的节点都是连通的，以此所有节点连接形成一个大的连通区域，所以控制流图的p一般为1. 即V(G)=e-n+2

2. V(G) = 判定节点数+1

3. V(G) = 控制流图中有界或无界的封闭区域个数

基路径测试步骤

1. 导出程序流程图的拓扑结构——控制流图（程序图）

2. 计算控制流图的McCabe圈复杂度（设为n）

3. 确定基本路径集，即构造n条独立路径

   1）任意构造一条从（唯一）入口节点到（唯一）出口节点的路径，将该路径加入基本路径集

   2）修改基本路径集中路径，至少经过一条以前未走过的边，将新路径加入基本路径集

   重复第2）步，直到基本路径集中包含n条路径

4. 设计测试用例，使基本路径集中的路径能走通

3 软件测试步骤与策略

单元测试：又称模块测试，是要检验程序的最小单位（模块）有无错误，它是在编码完成后进行的测试工作。

驱动模块(driver)相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果

桩模块(stub)用于代替所测模块调用的子模块。桩模块可以做少量的数据操作

集成测试：指每个模块完成单元测试以后，需要按照设计时确定的结构图，把它们连接起来，进行集成测试。

• 非增量式集成

  • 大爆炸集成

• 增量式集成

  • 自顶向下
  • 自底向上
  • 三明治集成

确认测试：确认测试又称为有效性测试和合格性测试。确认测试是在模拟环境下，利用一系列黑盒测试检验所开发的软件是否能按用户提出的要求进行工作。确认过程的重要环节就是配置审查工作。其目的在于确保已开发软件的所有文件资料均已编写齐全，并得到分类编目，足以支持投入运行以后的软件维护工作。

系统测试：系统测试是基于实际应用环境对计算机系统的一种多方位的测试，每一种测试都具有不同的目的，但所有的测试都是为了检验各个系统成分能否正确集成到一起并且是否能完成预定的功能

软件维护

软件维护：是指在软件的运行/维护阶段由软件厂商向客户所提供的服务工作。是在软件交付使用后，为了改正错误或满足新的需求而修改软件的过程。

• 纠错性维护/改正性维护：改正在特定的使用条件下软件中暴露出来的错误与缺陷，这些错误或缺陷在测试时并未被发现
• 适应性维护：使软件产品能够适应变化了的运行环境，如操作系统版本的升级、机器配置的变化、软件使用对象的变化等
• 完善性维护：为适应用户对软件功能、性能或接口方面提出的新要求以使产品更加完善与合理而进行的修改
• 预防性维护：提高产品的可靠性和可维护性，减少今后维护的工作量，有利于系统和进一步改造或升级换代而进行的维护

副作用：

• 代码副作用：对代码的修改最容易发生副作用，修改会使程序混乱、结构不清晰、可读性变差，而且会产生连锁反应。代码的副作用有时通过回归测试可以发现，一经发现应立即采取补救措施 。
• 数据副作用：数据结构是程序的骨架，在维护阶段一旦修改了数据结构，软件设计与数据可能就不再吻合，错误随即出现。容易产生数据副作用的修改包括：局部常量与全局常量的再定义、记录与文件格式的改变、增减数据结构的容积、修改全局数据、重新初始化控制标志与指针、重新排列I/O表或子程序的参数表、修改用户数据等
• 文档副作用：对软件的任何修改都应在相应的技术文档中反映出来，如果设计文档不能与软件当前的状况对应，则会比没有文档更糟。因为用户很多情况下都按照使用说明来使用软件

· 什么是UML；UML的特点；UML包含哪些模型图

· 重点：用例图、类图、状态图、顺序图、活动图

UML

标准建模语言UML是一种建模语言，而不是一种方法，它统一了面向对象建模的基本概念、术语及其图形符号，为人们建立了便于交流的共同语言

特点：

1. 统一标准
2. 面向对象
3. 可视化，表示能力强大
4. 独立于过程
5. 容易掌握使用

• 静态模型图/结构图

  • 类图：展示对象类、接口及其相互合作与关联

  • 对象图：展示对象及其相互之间的关系

  • 实现图

    • 构件图：描述部件的物理结构以及各部件之间的依赖关系
    • 配置图：定义系统中软硬件的物理架构

• 动态模型图/行为图

  • 用例图：从用户角度描述系统的行为，并指出各功能的操作者

  • 状态图：描述由事件驱动的系统/对象的状态转移

  • 活动图：描述活动之间的控制流，用于企业的工作流程建模

  • 交互图

    • 顺序图：描述消息发生的事件顺序
    • 合作图：描述各个对象之间收发消息的情况

类图

1. 关联关系：描述的是类与类之间的连接，表示一个类知道另一个类的属性和方法。可以是单向的或者双向的，一般以成员变量形式出现

   • 聚合关系：整体与部分、拥有的关系，且部分可以离开整体而单独存在（车和门、引擎）
   • 组合关系：整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束（大雁和翅膀）

2. 继承关系：类与类之间的继承关系

3. 实现关系：类与接口

4. 依赖关系：表示一个类依赖于另一个类的定义，一般来说，被依赖的对象往往是以局部变量、方法参数的形式存在于依赖对象中，与关联关系不同，它不会以成员变量的形式存在于依赖对象中

关联、集成、实现、依赖、聚合、组合

用例图

• 参与者（Actor）：与应用程序或系统进行交互的用户、组织或外部系统
• 用例：就是外部可见的系统功能，对系统提供的服务进行描述
• 子系统：用来展示系统的一部分功能，这部分功能联系紧密

• 关联：表示参与者与用例之间的通信，任何一方都可发送或接受消息

• 泛化

• 包含：表示一个用例的行为包含了另一个用例

• 扩展：常指用例功能的延伸，相当于为基础用例提供一个附加功能

顺序图

• 对象：对象、对象的生命线、激活的对象和对象的删除
• 消息：简单消息、同步消息、异步消息、返回消息
• 条件、注释体和注释连接

三对象模型：

• 实体对象：表示系统将跟踪的持久信息
• 边界对象：表示参与者与系统之间的接口和交互
• 控制对象：负责用例实现

1. 边界类位于系统与外界的交界处

   • 图形用户界面、窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类
   • 通过用例图可以确定需要的边界类，每个Actor/Use Case对至少要一个边界类，但并非每个Actor/Use Case对要唯一的边界类。

2. 实体类一般用于保存系统中要放进持久存储体的信息以及提供针对这些信息的相关处理行为

   持久存储体就是数据库、文件等可以永久存储数据的介质。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。

3. 控制类是控制其他类工作的类

   每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。

状态图

状态图描述系统对象的动态行为，一般描述一个特定对象在其生命周期中的所有可能状态以及由于各种事件的发生而引起状态的转移条件。

基本要素

• 状态

• 条件和转移

• 注释

• 持久性数据是系统关闭后必须要保存的数据

• 持久性数据的生命周期比系统的一次执行周期要长

• 数据的存储地点以及如何存储会对系统的分解产生影响

  • 比如仓库体系结构，某个子系统完全用于数据存储
  • 数据库管理系统的选择也对全局控制策略和并发管理有影响

• 主要存储策略：文件、数据库