第8章 软件工程

一、软件工程概述

（一）软件危机

1、含义：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
2、解决方案：引入软件工程的思想。

（二）软件工程

1、含义：《计算机科学技术百科全书》：软件工程是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。
2、目标：
在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。

（三）三个要素

1.方法

为软件开发提供了“如何做”的技术。方法覆盖面很广，包括沟通，需求分析、设计建模、程序构造、测试和技术支持。完成软件开发的各项任务的技术方法。

2.工具

为运用方法而提供的自动的或半自动的软件支撑环境。

3.过程

工作产品构建时所执行的一系列活动、动作和任务的集合。

二、软件生命周期

软件生命周期是指软件从产生到最终被废弃的生命周期，可以分为三大阶段，分别为定义问题、软件开发和软件维护，其中问题定义中的需求分析是软件开发和维护的前提，它直接决定软件项目的成败。

（一）软件生命周期图

1、可行性分析与项目开发计划（系统规划）

（1）此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标（是什么）及其可行性（怎么做可行）。
（2）主要产物：可行性分析报告和项目计划书

2、需求分析

（1）在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。
（2）得到逻辑模型，为整个项目的成功打下基础，也是开发过程中不断变化和深入的阶段。
（3）主要产物：软件需求说明书

3、软件设计（核心）

（1）概要设计+详细设计=软件设计
（2）得到物理模型

（3）概要设计：设计系统的结构，明确模块构成、层次、模块间调用方法、模块间通信方法、每个模块的功能等；系统整体的数据结构、数据库结构等；主要产物：概要设计书。对测试来说，这一阶段还需确认集成测试相关的东西。

（4）详细设计：比概要要细，完成每一个模块所对应的功能的具体描述==把每个模块的功能变成一系列的程序执行步骤的逻辑代码==生成程序流程图/程序框图。主要产物：详细设计说明书

4、编码

（1）软件设计阶段的程序流程图变成具体代码。
（2）将物理模型变成实际运行的代码。
（3）转成代码

5、测试

在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。

6、维护

（1）测试完成后，将软件放到生产环境中，进入运维阶段。
（2）运维阶段是软件生命周期中花钱最多、持续时间最长的活动。

（二）软件的生命周期

1、软件定义阶段

1.包括：问题定义、可行性研究、需求分析
2.软件定义阶段任务

2、需求

需求的层次

（1）业务需求

• 表示组织或客户高层次的目标。
• 系统最高的需求层次目标，确定系统开发的范围。

（2）用户需求

• 用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。

（3）系统需求

描述包含多个子系统的产品（即系统）的顶级需求。
包括 功能需求、非功能需求、设计约束；实际上还有行为需求，是通过系统的特性表现出来的，一般不考。

• 功能需求：系统必须实现的软件功能。
• 非功能需求：系统必须具备的一些属性，比如安全性、效率、可维护性、性能、可扩展性等。
• 设计约束：进行软件设计时的一些限制条件。

需求的特征

（1）完整性

每项需求必须描述清楚，使后面设计的人员可以获得所需的信息，包括设计和实现的所有必要信息。

（2）正确性

每一项需求都必须准确陈述要开发的功能。

（3）可行性

每一项需求必须是在已知系统和环境的全能和限制范围内可以实现。

（4）可验证性

检查每项需求是否能通过设计测试用例或其他验证方法开确定产品是否按需求实现。

解析：如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。而题中的需求是报表功能容易扩展，新的文件格式还是末知的情况下，无法验证该需求。

（5）必要性

每项需求都是编写文档的根源，每项需求都能追溯到具体用户需求。

（6）无歧义性（一致性）

对所有的需求，只有一个明确的统一解释。

3、概要设计

设计软件的结构、明确软件由哪些模块组成，这些模块的层次结构是怎样的，这些模块的调用关系是怎样的，每个模块的功能是什么。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。

概要设计的基本任务:

①、设计软件系统的总体结构(将系统按功能划分模块:确定每个模块的功能:确定模块之间的调用关系;确定模块之间的接口，即模块之间传递的信息;评价模块结构的质量);
②、数据结构及数据库设计；
③、编写概要设计文档；
④、评审
软件体系结构：是对子系统、软件系统组件以及它们之间相互关系的描述。

（1）设计软件系统总体结构

就是把系统切割成很多个小部分。

划分功能模块

模块功能和职责

模块间的调用关系

模块间的信息传递

评价模块结构的质量

（2）数据结构及数据库设计

• 需求分析、详细设计会涉及
• 概要设计对数据结构和数据库设计比较多。数据库设计有时在详细设计中。

4、详细设计

详细设计的基本任务

(1)对每个模块进行详细的算法设计。用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
(2)对模块内的数据结构进行设计。
(3)对数据库进行物理设计，即确定数据库的物理结构。
(4)其他设计。

代码设计

为了提高数据的输入、分类、存储和检索等操作，节约内存空间，对数据库中的某些数据项的值要进行
代码设计。

输入/输出设计

模块要接收的数据的数量、类型等。

用户界面设计

处理过程设计

模块要实现特定的功能，算法、具体步骤

其他设计任务

• 标准化设计
• 描述设计结果
• 拟定实施方案

（三）系统结构设计原则

为了保证系统设计工作的顺利进行，结构设计应遵循如下原则:
（1）所划分的模块其内部的凝聚性要强，模块之间的联系要少，即模块具有较强的独立性。
（2）模块之间的连接只能存在上下级之间的调用关系，不能有同级之间的横向联系。
（3）整个系统呈树状结构，不允许网状结构或交叉调用关系出现。
（4）所有模块(包括后继IPO图)都必须严格地分类编码并建立归档文件。

1、分解–协调原则

• 概要设计中将系统划分多个小模块
• 将系统看做一个整体，根据系统工程的思想，自顶向下逐层进行分解
• 分解出来的各模块共同协调完成特点功能

2、自顶向下的原则

3、信息隐蔽、抽象的原则

• 通过封装技术、封装机密信息于模块内，给用户看到的只是输入和输出的信息。处理逻辑如何实现，用户看不到。
• 把具体对象、行为、特征，进行分类总结后一步一步抽象成类、或者更高层的对象。

4、一致性原则

5、明确性原则

6、模块的扇入系统和扇出系数要合理

• 扇入系数：直接调用模块的上级模块的个数，扇入大，说明该模块的通用性越强，重复利用的机会比较高。
• 扇出系数：直接调用的下级模块的个数，扇出大，模块复杂度高，需要控制和协调过多的下级模块。扇出系数不宜过大或过小。

7、模块的规模适当

软考中参考值不宜超过500行。

（四）聚合与耦合（重点）

提高聚合程度，降低模块之间的耦合程度是模块设计应该遵循的最重要的两个原则。

1、聚合与耦合是衡量模块独立性的标准

2、聚合是衡量模块内各元素的紧密程度

3、耦合衡量不同模块间相互依赖的程度

4、考点

(1)七种聚合的排列顺序、七种耦合的排列顺序

(2)七种聚合的概念理解、七种耦合的概念理解

(3)考察方式：题干给具体的场景描述，让考生判定具体属于哪一种聚合或者耦合,

5、聚合

（1）偶然聚合

• 指的是模块完成动作之间的元素没有任何的关系，或者说仅仅是一种非常松散的关系。
• 简单理解就是把一些代码元素放到了这个模块中，但他们与这个模块功能的实现没有必然的关系。

（2）逻辑聚合

• 指一个模块内的各个组成部分的处理动作在逻辑上相似，但功能彼此不同或无关。
• 模块设计中，某模块根据输入的控制信息从文件中读一个记录或者向文件中写一个记录，则其内聚类型为逻辑聚合。

（3）时间聚合

• 模块内部各个组成部分所包含的处理动作，必须在同一时间执行。

（4）过程聚合

• 模块内部各组成部分所完成的动作虽然没有一个必然联系，但必须按照特定的次序完成。
• 完成一件事情，先后动作一定要按事先预定好的要求来。不利于重用。

（5）通信聚合

• 模块中各部分完成的动作都使用了同一输入数据，或者产生同一输出数据。

（6）顺序聚合

• 模块内的各部分，前一部分动作的输出是后一部分动作的输入。

（7）功能聚合

• 聚合程度是最强的，也是程序所追求的聚合状态。
• 模块内部各组成部分都为同一功能服务。

6、耦合（耦合程度由低到高）

（1）非直接耦合

• 模块间没有必然直接联系
• 通过主模块的控制和调用实现联系，所以模块间独立性比较好
• 修改其中一个模块时，无需考虑另一个模块。

（2）数据耦合

• 模块间有直接关系
• 模块间通过数据参数交换信息，即模块间存在通信

（3）标记耦合

• 模块间通过一组数据结构的子结构来传递信息记录。

（4）控制耦合

• 模块间传递给彼此信息包含有控制信息。

（5）外部耦合

• 模块间通过一个全局简单变量进行数据的传送。

（6）公共耦合

• 模块间有一个公共数据区域来传递信息。

（7）内容耦合

• 一个模块执行时需要到另一个模块内部获取信息。
• 耦合程度是最高的。

7、高内聚低耦合

符合这个标准=模块独立型好=后期可维护性高

（五）软件运维

1、系统可维护性的评价指标

• 可理解性
  理解、改正、改动、改进软件的难易程度。
  如结构、接口、功能和内部过程的难易程度。
• 可测试性
  测试和诊断软件错误的难易程度。
• 可修改性
  修改难易程度。

2、按照软件维护的性质

根据ISO-IEC14764划分
更正性维护:更正交付后发现的错误.
适应性维护:使软件产品能够在变化后或变化中的环境（运行环境/企业管理环境）中继续使用。
完善性维护:改进交付后产品的性能和可维护性。
预防性维护:在软件产品中的潜在错误成为实际错误前，检测并更正它们。将来存在的错误。

三、软件开发模型/方法（后三个是开发方法）

（一）瀑布模型

1、概念

• 瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括定义阶段、开发阶段、运维阶段。
• 整个过程分为软件计划、需求分析、软件设计、程序编码、软件测试、运行维护。

2、特点

• 易理解
• 管理起来成本低
• 强调早期需求分析阶段，需求需要明确。

3、缺点

• 客户必须能正确完整清晰的表达自己的需求。
• 定义阶段很难评估软件开发阶段的进度。

4、应用场景

• 主要用于需求明确、解决方案明确的项目。

（二）V模型

1、概念

• 对瀑布模型的改良，V模型纠正瀑布模型中对软件测试阶段的不重视。

2、特点

• V模型中软件测试阶段与系统开发阶段对应，将软件测试分为4个阶段：单元阶段、集成测试、系统测试、验收测试。
• V模型的软件测试策略包括低层测试（单元测试）和高层测试（验收测试）

3、缺点

• V模型有从根本上解决瀑布模型的问题。单元测试开始在程序编码阶段后，软件测试阶段相当于还是项目交付之前的尾部阶段进行的。

4、应用场景

• 主要用于需求明确、解决方案明确、对性能、安全要求较高的项目。

（三）原型

1、概念

• 原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制订原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。
• 创建的体现系统核心功能的，可运行的一个版本，叫做原型。
• 原型法是明确用户的需求后再进行一步步开发，最终的交付只有一次。

2、特点

• 最初不要求用户能够正确完整清晰的描述自己的需求。
• 便于与用户进行沟通，明确用户需求。

3、缺点

• 各个阶段都要求快速，整个软件生命周期中有部分工作来不及做。
• 采用抛弃型原型时，构建原型的工作可能会被浪费。

4、应用场景

• 主要用于需求不明确，需求动态变化（例如界面开发）的项目。

（四）增量模型

1、概念

• 增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
• 交付最终有很多次。增量n次就会交付n次。
• 结合了瀑布模型将软件生命周期按照活动规律分阶段再结合原型模型不断迭代的一种开发模型。

2、特点

• 客户只需描述出大概、主要需求，根据用户主要需求梳理用户核心要求，基于核心需求开发第一个版本交付。
• 分阶段分批次逐渐激发用户需求。
• 复杂系统分多次开发和交付，降低系统失败风险。

3、缺点

• 增量粒度不好衡量。
• 早期交付的系统在完整性、稳定性有问题，增大后期开发复杂度，重新部署难度。

4、应用场景

• 主要用于需求大部分明确、系统较为复杂，有一定技术风险的项目。

（五）螺旋模型

1、概念

• 螺旋模型采用周期性方法进行开发，结合演化原型法和瀑布模型。

2、特点

• 原型迭代，每个迭代又分为需求计划的制定、风险的分析、实施、评审。
• 螺旋模型最大特点是每一阶段都有风险分析。

3、缺点

• 风险分析需要有经验的分析人员来做，直接影响。

4、应用场景

• 主要用于庞大、复杂并具有高风险的系统。

（六）喷泉模型

1、概念

• 以用户需求为动力，以对象为驱动的一种开发模型。

2、特点

• 分析、设计、实现阶段可以重叠进行，可边做分析边做实现，这样就节约了开发时间。
• 阶段区分界限不是很明确，采用喷泉模型开发对文档要求比较严格。
• 适用于面向对象开发的软件。

3、缺点

• 阶段划分不是很明确，项目初期就需要投入大量人员，人员多了不利于项目管理。
• 对文档的审计难度会增加。
• 面向对象开发过程中，信息和需求在不断地增加，使得管理起来比较复杂。

4、应用场景

• 主要用于采用对象技术的软件开发项目。

（七）统一过程（RUP，rational unified process）

1、概念

• 以用例为驱动、以架构为中心迭代和增量的软件开发方法。

2、特点

• 将软件开发分为四个阶段：初始（确定项目的范围）、细化（对系统进行分析）、构建（实施）、交付（让用户进行必要的测试、对用户进行培训）。
• 初期阶段结束时：产生一个构想文档、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估和一个可以显示阶段和迭代的项目计划等制品；
• 精化阶段结束时：产生一个补充需求分析、一个软件架构描述和一个可执行的架构原型等制品；
• 构建阶段结束时：产生一个准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述；
• 移交阶段结束时：产生移交给用户产品发布版本。

3、统一过程模型中的相关概念

• 工件（制品）：活动产生的对象。进行开发活动所产生的一系列信息。（做什么）
• 活动：有明确目的的活动的单元。（怎么做）
• 角色：人。（谁做）
• 工作流：人完成一件事情的一系列的过程。（什么时候做）

（八）敏捷方法（Agile Development）

1、概念

• 整体目标是通过尽可能早的、持续的向客户交付有价值的产品，使客户满意。

2、特点

• 加入灵活性、敏捷性的方法，使得用户在开发过程中能够去增加需求、去改变他的需求。

3、敏捷方法

• 自适应开发
• 水晶方法
  认为每一个不同的项目都需要一套不同的策略、约定和方法论。
• 特性驱动开发
• 极限编程（XP）
  轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。
  由价值观、原则、实践和行为 4个部分组成。
  4大价值观：沟通、简单性、反馈和勇气。
  5个原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。

（九）结构化方法

1、指导思想

• 自顶向下、逐层分解，基本原则是功能的分解与抽象。
• 面向数据流的软件开发方法。

2、结构化设计原则

四、MVC

1、模型

• mvc核心，负责数据和业务逻辑处理规则的制定。

2、控制器

• 主要负责m和v之间请求的转换和处理。

3、视图

• 把运算的结果呈现给用户（用户界面），用web一些技术：xml等。

4、优点

• 低耦合性：MVC最大的特点就是解耦比较充分。将业务逻辑和用户界面分开了，修改用户界面不会影响业务逻辑和数据的存储；同样业务逻辑也不会影响用户界面。
• 高重用性：提高
• 可维护性：方便

五、能力成熟度模型

1、CMM（Capability Maturity Model for Software，软件能力成熟度模型）

• 对组织软件过程的描述，核心内容是将软件开发视为一个过程，并且根据相应的原则对于软件开发进行相应的监控和研究。
• 能力程度模型可以使软件组织更容易的去定位到当前过程的成熟度，识别出软件过程执行中的一些薄弱环节，定位对软件质量和过程改进最为关键的几个问题，从而形成对其过程改进的策略。

2、TMM（软件测试能力成熟度模型）

• 一些组织针对测试领域推出的模型。

3、CMM的五个分级

• 初始级：组织的软件过程是无序的，甚至是纷乱的状态。成功比较依赖于个人能力，特点是英雄主义。
• 可重复级：新的项目可以根据以往类似的项目的经验，也就是说把软件过程采用项目管理的方式来进行管理了， 可以对成本、功能、进度等方面的特性进行跟踪。建立基本的项目管理和实践来跟踪项目费用、进度和功能特性为可重复级的核心。
• 已定义级：建立了完善的培训制度以及专家评审制度。全部技术活动和管理活动均可以稳定实施。项目的质量和费用均得到了控制。使用标准开发过程(或方法论)构建(或集成)系统为已定义级的核心。
• 已管理级：这个级别对软件过程、产品质量有详细的度量标准。管理层寻求更主动地应对系统的开发问题为已管理级的核心。
• 优化级：在现有的基础上，通过对新概念、新技术等方面的应用和分析，能够不断地优化现有的过程。连续地监督和改进标准化的系统开发过程为优化级的核心。

4、TMM的五个分级

• 初始级
• 阶段定义级
• 集成级：完全定义。
• 管理和度量级：有详细的软件过程和产品质量的度量标准。
• 优化、缺陷预防和质量控制级：对现有过程能够进行定量分析，利用新概念、新技术不断地优化改进现有的过程。

六、分层体系结构

1、概念

• 将软件系统划分为多个层次，不同的层次负责不同的功能，以便更好的实现分离，每层只需考虑本层的功能而不是整个系统的功能。

2、优点

• 增加抽象层的设计，允许将一个复杂的问题分解成一个增量步序实现。简单理解就是将一个复杂的问题划分为多个层次，对不同的层次进行抽象。
• 越靠近底层抽象的级别越高，越靠近顶层抽象级别越低。
• 一个层次只影响相邻的两个层次，这样更有利于软件的复用， 加大了软件的重用。也就是说本层只需要向相邻的两层提供接口，允许他们调用即可。对于本身这一层是如何来实现软件的，相邻两层是不需要关心的。

3、缺点

• 一个系统如何进行分层，是不简单的问题。
• 很难找到一个合理的、合适的、正确的层次进行抽象。

4、三层体系结构

5、体系风格

七、面向对象

1、对象

• 客观事件基本运行时的一个实体，既包括属性特征（状态）及行为特征（方法）。

2、类

• 把对象的公共属性和行为进行抽象以后，就生成了一个能代表这一类对象的概念，叫做类。 也就是说类所包含的属性和方法，描述了一组对象共同的行为和属性。
• 对象和类的关系：对象是一个类的具体化；类是对一类对象整体的抽象。

3、抽象

• 把一组对象共同的属性和行为总结出来，形成一个类的过程叫做抽象。

4、封装

• 封装是把数据，以及操作数据的函数衔接在一起，而构成一个具有类类型的对象的描述。

5、继承

• 父子类之间共享数据和方法的机制叫做继承。

6、多态

• 对于同一个消息在不同的子类上面，产生出来的行为多种多样。即不同的对象调用同一个类产生的结果不同。
• 多态是通过对基类中的类才重新定义实现的。

7、接口

• 对操作规范的一个说明，也就是说明一个操作应该做什么、具体怎么去做是由接口指向的对象完成的。
• 例如接口定义了可以通过什么样的操作来调用一个模块，但这个模块中的功能是如何实现的，接口是不定义的，是由这个模块自己完成的。

8、消息

• 对象之间进行通信的一种构造。

9、组件

• 系统中可替换的物理组成部分，或者说是分装成模块功能的部分，就是组件。
• 例如计算机系统中硬盘、显卡都是可以替换的物理部分； 例如软件系统中封装成模块的实现部分。

10、复用

• 组件实现程序的可复用性，可复用就是利用现有的组件来开发新的软件。

11、模式

• 描述的是多半重复发生的问题，以及问题解决的方案。
• 一般来讲，模式由特定的环境、问题、解决方案这三个部分构成。

八、UML

（一）概念

• 统一建模语言，Unified Modeling Language。
• 面向对象设计的建模工具，独立于任何具体程序设计语言。

（二）三要素

1、事物

• 概念：对模型中作为代表性的成分的抽象。描述的是关键部件。
• 分类：
  ① 结构事物：是UML的静态部分，描述概念和物理元素，共有7种：类、接口、协助、用例、组件、节点、主动类。
  ② 行为事物：是UML的动态部分，描述跨越时间和空间的行为，共有2类：状态类、交付基类。
  ③ 分组事物：是UML的组织部分，包是模型分解成的盒子。
  ④ 注释事物：是UML的解释部分，负责标注和说明模型中的元素。

2、关系

• 把事物结合在一起。

3、图

• 展示相关的事物。

（三）UML关系

1、依赖（虚线+箭头）

• 是指两个事物之间的语义关系，其中一个事物是独立事物，发生变化会影响到另一个事物的语义。是一种比较弱的关系。

2、关联（直线）

一个雇员可以雇佣多个雇员。

• 关联关系展示的是一组链，就是对象之间的链接。

• 聚合、组合都描述的是整体和部分的关系，图示都表示特殊的关联关系。

• （1）聚合（空心菱形+箭头线）
  
  聚会是个整体，聚会结束后，参加聚会的人都还存在。

• 强调部分可以独立于整体。

• （2）组合（实心菱形+箭头线）
  
  皮衣和毛，皮衣不存在了要毛也没用。

• 强调部分依赖于整体，整体不存在，部分也就不存在了。

3、泛化（实线+空心三角形）

• 是一种特殊和一般的关系。特殊元素（子元素的对象）可以替代一般元素（父元素的对象）。一般用于面向对象中父类和子类之间的关系。

4、实现（虚线+空心三角形）

• 强调类元之间的语义关系，其中的一个类指定了由另一个类保证执行的契约（实现）。像接口，具体的实现就是由具体的类对象实现的。

（四）UML的图

1、静态建模机制（结构图）

静态建模机制描述的是系统的结构，或结构的深化和扩展。

（1）类图（静态视图）

• 方形表示类，上中下=类的名称（不可省略）+类的属性（特征）+行为（方法），类的属性和方法可以省略。
• 使用类图的三种方式：对系统词汇建模、对简单的协作建模、对逻辑数据库模式建模。

（2）对象图（静态视图）

• 显示了某一时刻的一组对象及它们之间的关系。
• 对象图可被看作是类图的实例，用来表达各个对象在某一时刻的状态。

（3）构件图（静态视图）

• 展现了一组构件之间的组织和依赖。
  

（4）配置图（部署图 静态视图）

2、动态建模机制（行为图）

描述的是系统的行为和动作。
（1）用例图（静态视图）

• 两种使用用例图的方式
  对系统的语境建模
  对系统的需求建模
• 用例之间的三种关系
  包含关系：一个用例的包含另一个用例的行为。基用例依赖于包含用例的执行结果，但二者不能访问对方的属性。基用例指向扩展用例。
  扩展关系：用例功能的延伸，扩展用例可选，如果缺少，不会影响基用例的完整性。箭头指向基用例。
  泛化关系：继承关系，子用例继承父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。指向父用例

（2）状态图（动态视图）

• 实心圆圈表示状态。

（3）活动图（动态视图）

• 是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。
• 使用活动的两种方式：
  对工作流建模
  对操作建模

3、交互图

（1）序列图（顺序图）

• 竖着的长方形表示控制焦点；虚线表示对象的生命线，表示对象的生成时间；大叉号表示对象销毁的时间。
• 是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。
• 序列图有两个不同于通信图的特征
  序列图有对象生命线
  序列图有控制焦点

（2）通信图（协作图）

• 强调收发消息的对象的结构组织
• 在早期的版本中也被称作协作图
• 通信图有两个不同于序列图的特性
  通信图有路径
  通信图有顺序号

（3）交互概览图

• 它描述交互(特别是关注控制流)
• 但是抽象掉了消息和生命线

（4）计时图

• 它描述对象状态随时间改变的情况
• 适合分析周期和非周期性的任务