UML2面向对象分析与设计 -- 可视化建模技术（可视化建模基础统一建模语言UMLUML 2组成结构UML 2概念模型：构造块通用机制架构应用UML 2建模：用例图活动图类图...）

Posted 2022-04-27 CodeJiao

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了UML2面向对象分析与设计 -- 可视化建模技术（可视化建模基础统一建模语言UMLUML 2组成结构UML 2概念模型：构造块通用机制架构应用UML 2建模：用例图活动图类图...）相关的知识，希望对你有一定的参考价值。

文章目录

导语：可视化建模技术
1.可视化建模基础
- 1.1 建模的目的
- 1.2 建模的基本原则
2 统一建模语言
- 2.1 选择UML
- 2.2 UML统一历程
3. UML 2组成结构
- 3.1 UML语法结构
- 3.2 UML语义结构
4. UML 2概念模型
5. 应用UML 2建模

导语：可视化建模技术

随着软件工程技术的发展，软件开发已经不仅仅是需要编码，而更多的是需要关注分析和设计过程。软件开发者为了能够有效地进行分析和设计活动，就需要相应的技术和工具来支持，它就是建模的技术。

传统的结构化方法提供了数据流图（Data Flow Diagram, DFD）、实体关系图（Entity Relationship Diagram, ERD）、结构图（Structure Chart, SC）、流程图（Flow Diagram, FD）等各种建模技术来支持结构化分析（Structure Analysis,SA）和结构化设计（Structure Design, SD）。在20世纪90年代初，这些方法最终得到了统一，并最终形成了统一建模语言（Unified Modeling Language, UML）。UML也迅速成为面向对象分析和设计的标准表示法，并被广泛应用。

1.可视化建模基础

在软件世界中，模型就是对目标系统进行简化，提供系统的蓝图。模型可以仅列出系统高层的组织结构，也可能包含各个组成部分的细节信息。每个系统都可以从不同的方面分析构建不同的模型，可能是静态的结构，也可能包含动态的信息。

1.1 建模的目的

建模的根本目的是能够更好地理解待开发的系统。当我们不能够完整地理解一个复杂的系统时，就需要对其进行建模。开发人员通过建模，可以把一个复杂系统划分成一系列易于理解的小的组成部分，分而治之。通过建模，可以达到以下4个目的。

模型有助于按照所需的样式可视化（Visualize）系统。模型可以为开发团队提供待开发系统的可视化表示，从而使团队成员对系统有统一的理解。
模型能够描述（Specify）系统的结构和行为。模型允许用户在构造系统前准确地描述其结构和行为。
模型提供构造（Construct）系统的模板。模型为开发人员提供了开发实现的依据，开发人员可以根据模型（而不是原始的需求）构造目标系统。
模型可以文档化（Document）设计决策。开发人员通过模型，可以将开发过程中的设计决策记录成文档，并长期保存，便于以后参考和使用。

说明：

建模并不只是针对大型系统，甚至像“计算器”这样一个很简单的软件也能从建模中受益。然而，可以明确的一点是，系统规模越大，模型的重要性级别就越高。例如，当构造一架大型客机时，必须要事先构造各种不同的模型；而当叠一架纸飞机时，显然就没有必要花太多的精力去提前构造模型了。

1.2 建模的基本原则

选择合适的模型。
模型具有不同的精确程度。面向不同的用户，开发人员需要提供不同抽象层次的模型。有时一个简洁且可执行的用户界面模型正是用户所需要的，而有时则需要耐心地描述每一个细节。
好的模型是与现实相联系的。模型是对现实的简化，但最关键的是简化不能掩盖掉任何重要的细节。
需要从多个视角创建不同的模型，单一的模型是不够的。为了更好地解读系统，我们经常需要添加几个互补/连锁的视图，例如用例视图，揭示系统需求；逻辑视图，揭示软件内部设计逻辑。这些视图从整体上描绘了软件开发蓝图。

2 统一建模语言

统一建模语言是由对象管理组织（Object Management Group, OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化、描述、构造和文档化软件密集型系统的各种工件。这种建模语言已经得到了工业界的广泛支持和应用，并已被ISO确立为国际标准。在选择UML建模时，需要注意以下几个方面的问题。

UML不是一种程序设计语言，而是一种可视化的建模语言。它比C++、Java这样的程序设计语言抽象层次更高，可以适用于任何面向对象的程序设计语言。
UML不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种模型表示的标准。
UML不是过程，也不是方法，但允许任何一种过程和方法使用它。

2.1 选择UML

在面向对象的软件开发中，选择UML已经成了必然的趋势。在很多情况下，开发人员都应该选择UML作为建模语言。

2.2 UML统一历程

UML的产生和发展历程：目前，UML 2已经成为发展趋势，我们选择UML 2.5作为建模语言。

作为一种统一建模语言，UML的统一并不仅仅是三大面向对象方法的统一，还合并了许多面向对象方法中被普遍接受的概念，对每一种概念，UML都给出了清晰的定义、表示法和有关术语。此外，UML还尝试统一几种不同领域等，具体包括以下内容。

开发生命周期：UML对于开发的要求具有无缝性，即在软件开发生命周期的各个阶段都可以采用UML。这种无缝性对迭代的增量式软件开发（强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的程。）至关重要。
应用领域：UML适用于各种应用领域的建模，包括大型复杂分布式系统、实时嵌入式系统、集中式数据或计算系统等。当然，也许用某种专用语言来描述一些专门领域更有用，但在大部分应用领域中，UML不比其他的专用语言逊色，甚至更好。
实现语言和平台：UML可应用于各种不同的编程实现语言和开发平台系统。无论是采用Java、C++、C#等程序设计语言和开发工具，还是使用Windows、Linux等不同的操作系统，均可以采用UML进行建模。
开发过程：UML是一种建模型语言，不是对开发过程的细节进行描述的工具。就像通用程序设计语言可以用于许多风格的程序设计一样，UML适用于大部分现有的或新出现的开发过程，尤其适用于类似敏捷过程、统一过程等迭代增量式开发过程。
自身的内部概念：在构建UML元模型的过程中，特别注意揭示和表达各种概念之间的内在联系，并试图用多种适用于已知和未知情况的办法去把握建模中的概念。这个过程会增强用户对概念及其适用性的理解。这不是统一各种标准的初衷，却是统一各种标准所得到的最重要的结果之一。

3. UML 2组成结构

3.1 UML语法结构

在UML规范中，主要采用UML类图来描述各元素的抽象语法，采用约束机制和自然语言（文本）来描述模型语义。

3.2 UML语义结构

UML自身的语义与被建模系统的UML模型上所声明的标准含义有关，有时被称为UML运行时语义。通常，我们可以把UML模型划分为两类语义域。

结构语义（Structural Semantics）定义了在建模域中关于个体的UML结构化模型元素的含义，这个含义可能只在某个特定的时间点是正确的。该类别有时也称为静态语义。
行为语义（Behavioral Semantics）定义了在建模域中关于个体如何随着时间变化而做出不同行为的UML行为模型元素。该类别有时也称为动态语义。

下图来自UML 2.5规范，列出了UML语义域分层的详细分解结构。UML 2.5规范文本的主体内容就是按照该结构组织的。

UML结构语义为行为语义提供基础，通过结构化建模所规定的模型元素的状态变化而形成行为语义的概念。UML结构模型建立在一个通用的基础结构（CommonStructure）之上，包括类型、命名空间、关系和依赖等概念。CommonStructure具体的建模元素包括不同的分类器（Classifiers），这包括数据类型、类、信号、接口和构件等；此外还包括简单的值类型（Values）和包（Packages）等。
构建在基础结构之上的UML基本行为语义为行为的执行提供了一个基本框架，通用行为（Common Behavior）语义还定义了结构化对象之间通过相关行为产生的通信。动作（Actions）是UML中的基本行为单元，用于定义细粒度的行为；在此基础上形成高层次的行为机制，包括状态机（State Machines）、活动（Activities）和交互（Interactions）等。
此外，还提供了一些既有结构化又有行为的辅助建模结构，包括用例（UseCases）、部署（Deployments）和信息流（Information Flows）。

4. UML 2概念模型

UML 2规范按照语义结构组织，详细阐述了各类模型元素的语法结构，然而规范中的介绍面面俱到，普通用户很多时候只使用那些最常用的属性。因此，对于普通建模用户来说，更多的还是从业务角度考虑问题，例如为目标系统建模，需要哪些建模元素、涉及哪些基本概念等。这些核心概念形成了UML的概念模型。

UML概念模型主要由三部分组成：构造块、运用于这些构造块的通用机制和组织UML视图的架构。每个部分又包含不同的子部分，具体的组成结构如图所示。

4.1 构造块

构造块（Building Blocks）是指UML的基本建模元素，包括事物（Thing）、关系（Relationship）和图（Diagram）3个方面的内容。事物是对模型中核心要素的抽象；关系把事物紧密联系在一起；而图是由很多相互关联的事物组成的。

4.1.1 事物（Thing）

在UML中，事物代表了基本的面向对象构造块，主要包括以下4种类型的事物。

结构事物（Structural Thing）是UML模型中的名词。它们通常是模型的静态部分，用于描述概念元素或物理元素。常见的结构事物包括类、接口、用例、协作、构件、工件、节点等。
行为事物（Behavioral Thing）是UML模型中的动词。它们是模型的动态部分，代表了跨越时间和空间的行为。常见的行为事物包括交互、状态机、活动等。
分组事物（Grouping Thing）是UML模型的组织部分，用于将模型元素组织在一起。主要的分组事物是包，还有其他的诸如子系统、层等基于包的扩展事
注释事物（Annotational Thing）是UML模型的解释部分，用来描述、说明和标注模型的任何元素。最重要的注释事物就是注解（Note），它是依附于一个元素或一组元素之上对元素进行约束或解释的简单符号，所有的UML图形元素均可以用注解来说明。

4.1.2 关系（Relationship）

关系将UML的事物连接起来，构造出结构良好的UML模型。在UML中有4种基本关系：依赖、关联、泛化和实现。关系的详细说明

依赖（Dependency）是两个事物间的弱语义关系，表明两个事物之间存在着一种使用关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。依赖关系的箭头表明了依赖的方向，即没有箭头端的事物依赖于有箭头端的事物。
关联（Association）是一种强语义联系的结构关系，表明两个事物之间存在着明确的、稳定的语义联系。它描述了一组链接（link），链接是事物的具体实例之间的关联（如类之间的关联，则意味着类的对象之间存在链接）。聚合（Aggregation）是一种特殊类型的关联，它表明关联的两个事物之间还存在一种整体和部分的语义联系。图中的关联关系两端都没有标注箭头，这并不意味着关联关系没有方向，默认情况下关联的方向是双向的，也就是说，两个关联的事物之间互相依赖。如果要标注单方向的依赖，则需要在关联的一端标注箭头。
泛化（Generalization）关系也就是继承关系，用于描述父类与子类之间的关系，父类又称为基类或超类，子类又称为派生类。
实现（Realization）是两个事物之间的一种契约关系，其中的一个事物（箭头指向的事物）描述了另一个事物必须实现的契约。在两种位置会遇到实现关系：
- 一种是在接口和实现它们的类或构件之间；
- 另一种是在用例和实现它们的协作之间。

这4种元素是UML模型中可以包含的基本关系事物。它们也有扩展和变体，例如，依赖关系就可以扩展为包含、扩展、精化、跟踪等关系，而关联关系还有聚合、组合等变体的形式。

4.1.3 图（Diagram）

图（Diagram）是一组元素的图形表示，它是模型内的视图，可以通过图将模型展示给用户。图不是模型本身，有的模型元素可以出现在所有图中，有的模型元素可以出现在一些图中（很常见），还有的模型元素不能出现在图中（很少见）。此外，事物或关系可能从图中被删除，甚至从所有的图中被删除，但是它们仍然可以存在于模型中。

4.2 通用机制

UML提供了4种通用机制，它们被一致地应用到模型中，描述了达到对象建模目标的4种策略，并在UML的不同语境中被反复运用。这4种机制如下所示。

规格说明（Specifications）：文本维度的模型描述。
修饰（Adornments）：描述建模元素的细节信息。
通用划分（Common Divisions）：建模时对事物的划分方法。
扩展机制（Extensibility Mechanisms）：用于扩展UML建模元素，包括构造型、约束和标记值3类机制。

4.2.1 规格说明

UML不仅仅是一种图形语言，实际上，在UML表示法的每部分背后都有一个文本维度的规格说明，这个规格说明提供了对构造块的语法和语义的文字叙述。

4.2.2 修饰

UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节添加到这些符号上。这意味着，能够仅使用带有一个或两个修饰的基本记号来构造非常高级的模型。然后，可以精化模型，添加越来越多的信息，直到模型元素对于目标来说是足够详细的。

在使用修饰时，需要注意的是，任何UML图仅是模型的视图，只有在修饰增强了图的整体清晰性和可读性或者突出模型的某些重要特征时，才应该表示那些修饰。下图展示了一个没有修饰元素和有部分修饰元素的类。这两个元素都表示一个Window类，它们内部含义是一样的，只不过在当前视图中展示了不同的信息。

4.2.3 通用划分

在对面向对象系统建模中，通常有以下3种对元素进行分类的通用方法。

第一种是类元（Classifier）和实例的划分。类元表示一种抽象，实例则是这种抽象的一个具体表现。在UML中，很多概念都是基于这种划分方法建立的，例如，类和对象、用例和场景、构件和构件实例等。
第二种是接口和实现的分离。接口声明行为的契约（做什么），实现表示对该契约的具体实现细节（如何做）。例如，接口和子系统、用例和用例实现、操作和方法等。
第三种是类型和角色的分离，这是UML 2新增的划分方法。类型声明实体的种类（如对象、属性、参数），而角色描述实体在语境（如类、构件、协作、组合结构）中的含义。任何作为其他实体结构的一部分实体（如属性）都具有两个方面的特性：从固有类型派生出来的含义和在语境中的角色派生出来的含义。下图展示了组合结构中的customer对象，作为Person类，customer对象具有Person类所提供的属性和行为；同时，作为组合结构TickOrder（订票系统）中的角色，customer是一个订票的顾客。

4.2.4 扩展机制

UML提供了一种绘制软件蓝图的标准语言，但是不可能简单地设计一种能满足现在和将来所有人需要的完全通用的建模语言。为此，UML提供了灵活的扩展机制，可以以受控的方式扩展该语言。UML提供了3种扩展机制。

构造型（Stereotype）：基于已有的建模元素引入新的建模元素。
标记值（Tagged Value）：扩展UML构造型的特性，可以用来创建构造型的详细信息。
约束（Constraint）：扩展UML构造块语义，可以用来增加新的规则或修改现有规则。

下图展示了在类EventQueue上添加这3种扩展机制。

其中类名前面的<<authored>>是构造型（名称被放在<< >> 里面），表明该类不同于其他的类，它具有版权信息（具体的含义在扩展时定义）；
信息的细节通过注解框中的标记值来表示；
该类的add（）操作添加了ordered约束（名称被放在“ ”里面），表明在插入数据时需要排序。

构造型是一种应用非常广泛的扩展机制，可以用于所有的UML模型元素，如类、关联、用例、构件等。此外，为了更形象地表示构造型，很多建模工具也以可视化的形式来表示不同的构造型。例如<<entity>>构造型，这是一个在分析建模过程中被大家广泛认可的针对类的扩展概念，表示分析模型中的一个实体类。下图展示了该构造型可能的3种表现形式。其中第一种是标准表示（在类名前面用<< >>表示），第二种是在类的右上角用特殊的图标表示，第三种是直接采用全新的图形符号表示。

4.3 架构

一种被大家广泛接受的UML架构是源自统一过程中所提供的“4+1”架构模型，该架构如图所示。

用例视图（Use-Case View）：建模过程的起点和依据，面向最终用户，描述系统的功能性需求。所有其他视图都是从用例视图派生而来的，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础。
逻辑视图（Logical View）：面向系统分析和设计人员，描述软件结构。它来自功能需求，用于描述问题域的结构。作为类和对象的集合，它的重点是展示对象和类是如何组成系统、实现所需系统行为的。
进程视图（Process View）：面向系统集成人员，描述系统性能、可伸缩性、吞吐量等信息。其目标是为我们系统中的可执行线程和进程建模，使它们作为活动类。事实上，它是逻辑视图面向进程的变体，包含所有相同的工件。
实现视图（Implementation View）：面向编码人员，描述系统的组装和配置管理。其目标是对组成基于系统的物理代码的文件和构件进行建模。
部署视图（Deployment View）：面向系统工程师，描述系统的拓扑结构、分布、移交、安装等信息。建模的目标是把组件物理地部署到一组物理的、可计算的节点（如计算机）上。

5. 应用UML 2建模

UML 2提供了两类（结构图和行为图）14种图形用于系统建模。

类图：描述类、接口、协作及它们之间的关系。
对象图：描述对象及对象之间的关系。
包图：描述包及包之间的相互依赖关系。
组合结构图：描述系统某一部分（组合结构）的内部结构。
构件图：描述构件及其相互依赖关系。
部署图：展示构件在各节点上的部署。
外廓图：展示构造型、元类等扩展机制的结构。
顺序图（也称时序图）：展示对象之间消息的交互，强调消息执行顺序的交互图。
通信图：展示对象之间消息的交互，强调对象协作的交互图。
时间图：展示对象之间消息的交互，强调真实时间信息的交互图。
交互概览图：展示交互图之间的执行顺序。
活动图：描述事物执行的控制流或数据流。
状态机图：描述对象所经历的状态转移。
用例图：描述一组用例、参与者及它们之间的相互关系。

需要说明的是，早期的UML 1.x只提供了9种图形。包图、组合结构图、外廓图、交互概览图、时间图这5种是在UML 2中新增的（外廓图是在UML 2.3之后才有的）；通信图则是由UML 1.x的协作图改名而来，其他的一些图形也做了适当的调整和扩充。

为了能够系统地讲解各类UML图的应用，本节以一个图书馆管理系统为例，对13种UML图（外廓图除外）的应用进行详细介绍。该图书馆管理系统的原始需求如下所示。

该系统是一个基于Web的计算机应用系统。
读者可以查询图书信息及借阅信息。
读者可以通过系统预约所需的图书。
图书馆工作人员利用该系统完成读者的借书、还书业务。
图书馆工作人员可以对图书信息、读者信息等进行维护。
对于到期的图书，系统会自动向读者发送催还信息。
管理员会定期进行系统维护。

5.1 用例图

对于该图书馆管理系统，首先需要描述其功能。将在UML中采用用例模型（包括用例图和它的规格说明）来进行描述。

用例图（Use Case Diagram）是被称为参与者的外部用户所能观察到的系统功能的模型图，其主要功能如下所示。

列出系统中的用例和参与者。
显示哪个参与者参与了哪个用例的执行工作。

用例图中的核心概念包括以下几个。

用例（Use Case）：系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。
参与者（Actor）：通过系统边界与系统进行有意义交互的外部实体。
泛化：参与者与参与者之间的关系。
关联：用例与参与者之间的关系。
扩展、包含、泛化：用例之间的关系。

用例图的推荐使用场合：包括业务建模、需求获取和定义等场合。

下表列出了用例图中的主要建模元素。需要说明的是，由于注解和注解链接在所有的UML图中均可使用，因此本章后面各类图形的建模元素讲解中将不再包含这两个元素。

在图书馆管理系统中，读者、工作人员、管理员等作为参与者，可以利用该系统完成借书、还书、预约图书、查询图书、维护图书 / 读者信息、维护系统等功能单元操作，这些功能单元便构成了一个个的用例。此外，系统定期检测到期图书并发送催还消息，也可以构成一个用例，该用例由系统时间自动启动。该系统的用例图如图2-15所示。

通过用例图，我们可以获得用户使用系统的情况，但是具体的使用过程又是怎样的呢？例如，读者到底是怎么预约图书的、工作人员又是如何为读者完成借书操作过程的，用例图中没有展示这些流程信息，这时候开发人员需要编写该用例图文本维度的规格说明——用例文档。用例模型中的每一个用例都需要开发人员为其编写相应的用例文档。

5.2 活动图

用例文档描述了用例的业务流程，有些用例的流程比较复杂（如存在分支、循环等复杂结构），只用文本描述这个流程并不直观，且不利于用户之间的沟通。此时，开发人员可以采用活动图来描述该用例内部的执行流程。

活动图（Activity Diagram）是一种动态行为图，将业务流程或其他计算的结构展示为内部一步步的控制流和数据流，主要用于描述某一方法、机制或用例的内部行为。活动图中的核心概念包括以下几个。

活动、组合活动：表示某个内部的控制逻辑。
对象、对象流：与活动相关的数据对象。
转移、分支：控制活动之间的先后顺序。
并发、同步：支持活动间的并发和同步。
分区：描述活动的不同参与者。

活动图的推荐使用场合：包括业务建模、需求、类设计等场合。下表列出了活动图中的主要建模元素。

图书馆管理系统用例模型中的用例，特别是复杂的用例，均可以用活动图来表示。图2-16展示了借书用例的活动图，开发人员可以把该活动图放在用例文档的“相关图”部分。

5.3 类图、对象图、包图和组合结构图

描述完需求后，开始对系统进行分析和设计。UML提供了4种静态结构图来描述系统。

类图（Class Diagram）是软件的蓝图，用于详细描述系统内各个对象的相关类，以及这些类之间的静态关系；
对象图（Object Diagram）用于表示在某一时刻，类的对象的静态结构和行为；
包图（Package Diagram）用于展现由模型本身分解而成的组织单元（包）及它们的依赖关系；
组合结构图（Composite Structure Diagram）用于描述系统中某一部分（组合结构）的内部结构，包括该部分与系统其他部分的交互点。

静态结构图中的核心概念包括以下几个。

类图：类、接口、依赖、关联、泛化、实现。
对象图：对象、链接、多重性。
包图：包（框架、层、子系统）、依赖。
组合结构图：组合结构、部件、端口、角色绑定。

静态结构图的推荐使用场合：包括业务建模、分析、设计、实现等场合。

下表列出了类图、对象图和包图中的主要建模元素。

下表列出了组合结构图中的主要建模元素。作为UML 2新增的模型图，目前组合结构图被应用得并不是很广泛。

5.3.1 类图

对于图书馆管理系统，通过类图可以反映该系统内部的静态结构特征（类和类之间的关系）。图2-17所示的类图就展示了图书类（Book）、借阅信息类（BorrowInfo）、读者类（Reader）之间的静态关系。其中，图书分为不同的类别（Catalog），如科技书（TechBook）、文学书（LitBook）、新书（NewBook），而读者分为学生（Student）和教职工（Faculty）。

5.3.2 对象图

对象图则用于展示某一时刻对象之间的关系。图2-18所示的对象图展示了一名教职工（thbin）的个人借阅信息（myInfo），他一共借了4本书：一本新书（book1）、两本科技书（book2、book3）和一本文学书（book4）。

5.3.3 包图

包图展示了软件系统的分层结构。在图书馆管理系统中，如图2-19左半部分所示，系统高层分为3层，其中界面层负责用户交互；数据访问层负责访问底层信息；业务逻辑层负责协调界面层和数据访问层间的访问逻辑。此外，对于数据访问层内部，又可以采用分包的方式进行逻辑划分，如图2-19右半部分所示，分为借阅包、读者包、图书包。

5.3.4 组合结构图

作为一种新增图形，组合结构图主要反映的是系统某一部分内部结构的组成。为了完成系统所需的某些功能（如借书），需要几个类之间进行相互协作，而这几个类就构成了一个组合结构。为了完成借书的功能，这些类之间存在着一定的接口（组合结构图中称为端口）和连接，这些信息即可通过组合结构图来反映。图2-20展示了借书过程的组合结构图，为了完成借书的过程，在该图中需要设置借阅用户界面类（BorrowUI）、借阅控制类（BorrowCtrl）、借阅信息类（BorrowInfo）、读者类（Reader）和图书类（Book）。

5.4 顺序图

分析完静态结构后，本小节描述对象之间的动态交互行为，需要用到动态交互图，而顺序图就是一种最常用的动态交互图。顺序图（Sequence Diagram）用于显示对象间的交互活动，它关注对象之间消息传送的时间顺序。顺序图中的核心概念包括以下几个。

对象、生命线、执行发生、消息。
交互片段（Interaction Frame）：UML 2中的新增概念，用于封装交互图中的片段，并可对片段施加一定的操作（如选择、循环、并行等），从而使UML支持复杂的交互建模。

顺序图的推荐使用场合：包括用例分析、用例设计等场合。

下表列出了顺序图中的主要建模元素：

图2-21所示的顺序图描述的是为了完成借书的过程，系统中的对象是如何进行交互的。

图2-21是UML 1.x版本的顺序图，可以看到，其中的第2步“录入图书信息”是一个循环的过程，第2.1.1步存在一个选择（如果失败了该怎么做），而这些信息无法直接在图中描述（只能通过注解或标记的方式表示）。为此，UML 2引入了交互片段的概念来解决这个问题，通过交互片段可以很方便地实施各种复杂的逻辑，如图2-22所示（loop操作表示循环、alt操作表示选择）。

5.5 交互概览图（描述属顺序图之间的关系）

当一个用例内部的交互行为非常复杂时，通过一个顺序图可能无法很好地表示出来，这时候可能会把该用例的行为拆分成几个顺序图。此时，这几个顺序图之间的关系就可以通过交互概览图来描述。交互概览图（Interaction OverviewDiagram）是活动图和顺序图的混合体，它将直观地表达一组相关顺序图之间的流转逻辑。交互概览图中的核心概念包括以下几个。

交互片段。
起点、终点、决策、转移。

交互概览图的推荐使用场合：包括用例分析、用例设计等场合。

下表列出了交互概览图中的主要建模元素。

作为UML 2新增的模型，交互概览图的使用场合并不多，而且目前许多支持UML 2建模的工具也不支持该图的建模。图2-23展示了某读者使用系统的一段流程，其中每个交互片段内部对应另外一个顺序图，通过ref算子来引用。

5.6 通信图（协作图）

通信图（Communication Diagram），在UML 1.x中称为协作图（Collaboration Diagram），表示一组对象之间的关系及交互活动。通信图和顺序图是同构的（描述的能力相同，很多工具提供了自动相互转换功能），只是侧重点不同。通信图中的核心概念包括以下几个。

对象、协作角色。
协作、交互、消息。

下表列出了通信图中的主要建模元素。

图2-24所示的通信图描述的是为了完成借书的过程，系统中的对象是如何进行交互的（该图与图2-21的顺序图所描述信息完全相同，可以体会一下它们的不同点）。

5.7 时间图

对于一些特定的系统（如实时系统），有时候真实的时间信息非常重要（如某个消息在发送出去后，在1s之内必须返回）, UML 2引入了新的时间图来描述时间信息。

时间图（Timing Diagram）是一种交互图，用于展现消息跨越不同对象或角色时真实的时间信息，可描述单个或多个对象状态变化的时间点及维持特定状态的时间段。此外，顺序图作为表示交互的主要手段，也可以在其中增加时间约束来表明对象状态变化的时间点及维持特定状态的时间段。时间图中的核心概念包括以下几个。

时间约束、持续时间约束、生命线。
状态、条件、事件。

下表列出了时间图中的主要建模元素。作为一种新增的UML图形，目前大部分建模工具都不支持时间图的建模。

作为一种全新的UML模型，目前时间图还没有得到广泛推广。此处以打电话的场景为例，说明时间图的使用方法。在打电话的过程中，电话机处于不同的状态（如空闲、拨号音、拨号、连接、通话等）；当用户拿起电话后，电话提示拨号音，之后必须在一段时间内完成拨号动作（如30s），否则电话会自动挂起。为了表示这30s的时间顺序，可以通过在顺序图中添加约束来表示，如图2-25所示。

涉及这种真实时间信息的交互，采用时间图可以更方便地描述。时间图有两种表示状态的方法，一种是通过直线的方式，另一种是通过区域的方式，分别如图2-26和图2-27所示。

5.8 状态机图

顺序图和通信图都是交互图的一种，它们侧重于描述对象之间的交互过程。然而，有时候对象本身也是很复杂的，它可能涉及不同的状态和行为，此时需要通过状态机图来表示。

态机图（State Machine Diagram），就是UML 1.x中的状态图（StatechartDiagram），利用状态和事件描述对象本身的行为。它是一种非常重要的行为图，强调事件导致的对象状态的变化。状态机图中的主要概念包括以下几个。

状态、初态、终态。
事件、转移、动作。
并发状态机。

状态机图的推荐使用场合：包括类设计场合。

下表列出了状态机图中的主要建模元素：

在图书馆管理系统中，图书涉及不同的状态：新采购的图书处于“待入库状态”，当工作人员完成新书入库的操作后（如登记图书信息等），该图书的状态就转为“待借状态”，图书借出后即转为“借出状态”，归还后又转为“待借状态”，如此循环。图2-28展示了整个状态演变过程，而这些状态同时会影响它的行为，如在“借出状态”的图书就不允许再借出了。

UML中的动态图主要可以分为交互图和行为图两大类，它们都是非常有价值且容易混淆的，此处简单总结几种动态图的使用方法。它们的共同点有以下几个。

描述系统中单个或多个事物动态行为特性。
交互图（顺序图、通信图、交互概览图、时间图）侧重描述事物间的交互过程。
行为图（活动图、状态机图）侧重描述事物本身的行为特征。它们的区别主要体现在每种图形的侧重点不同。
交互图（顺序图、通信图）：适合描述单个用例中多个对象之间的协作行为。
交互概览图：用于描述复杂用例多个顺序图间的控制流程。
时间图：用于描述时间受控的单个或多个对象间状态交互。
状态机图：适合描述跨越多个用例的单个对象的行为如何影响该对象的状态。
活动图：适合描述多个对象跨越多个用例时的总貌。

5.9 构件图和部署图

5.9.1 构件图

构件图（Component Diagram）将封装类作为构件，描述在系统实现环境中的软件构件和它们之间的关系。构件图中的主要概念包括以下几个。

构件、工件、接口（所供接口、所需接口）。
装配连接、委托连接、依赖。

构件图的推荐使用场合包括系统设计、实现、部署等。

下表列出了构件图中的主要建模元素。

在图书馆管理系统中，可以定义5个构件（界面、业务逻辑、借阅、读者、图书），这些构件代表实现时的概念（如源代码、目标文件等）。在这些构件中可实现那些设计时的类，其构件图如图2-29所示（由于采用Rose绘制，因此图中的构件采用UML 1.x语法，构件的图符有所不同）。
在构件图中，所供接口和所需接口的概念是在UML 2中新引入的（UML 1.x只有接口的概念，特指所供接口），图2-30展示了UML 2中构件的扩展。

5.9.2 部署图

部署图（Deployment Diagram）描述系统所需的硬件环境的物理结构，以及软件资源在硬件环境中的部署方案。部署图中的主要概念包括以下几个。

节点、工件、部署规范。
连接、依赖。

下表列出了部署图中的主要建模元素：

图2-31是图书馆管理系统的部署模型，从图中可以看到，该系统共有4类不同的节点。其中读者客户端面向普通读者提供查询、预约等功能；工作人员前置机面向工作人员用于实现具体的借书、还书业务；后台数据库用于运行系统数据库环境；管理员后台用于帮助管理员实现各种系统维护功能。