UML - 快速指南

上一个

下一个

UML - 概述

UML 是一种用于规范、可视化、构建和记录软件系统构件的标准语言。

UML 由对象管理组 (OMG) 创建，UML 1.0 规范草案于 1997 年 1 月提交给 OMG。

OMG 不断努力创建真正的行业标准。

UML 代表统一建模语言。
UML 不同于其他常见的编程语言，如 C++、Java、COBOL 等。
UML 是一种图形语言，用于创建软件蓝图。
UML 可以被描述为一种通用的可视化建模语言，用于可视化、规范、构建和记录软件系统。
虽然 UML 通常用于建模软件系统，但它并不局限于此。它也用于建模非软件系统。例如，制造单位中的流程流程等。

UML 不是一种编程语言，但可以使用工具使用 UML 图生成各种语言的代码。UML 与面向对象分析和设计有直接关系。经过一些标准化后，UML 已成为 OMG 标准。

UML 的目标

一图胜千言，这个习语绝对适合描述 UML。面向对象的概念比 UML 早得多。在那个时候，还没有标准的方法来组织和整合面向对象的开发。正是那时，UML 出现了。

开发 UML 有许多目标，但最重要的目标是定义一些通用建模语言，所有建模者都可以使用它，并且它也需要易于理解和使用。

UML 图不仅面向开发人员，也面向业务用户、普通用户以及任何对理解系统感兴趣的人。系统可以是软件或非软件系统。因此必须明确，UML 不是一种开发方法，而是伴随着流程使其成为一个成功的系统。

总之，UML 的目标可以定义为一种简单的建模机制，用于建模当今复杂环境中所有可能的实际系统。

UML 的概念模型

要理解 UML 的概念模型，首先我们需要澄清什么是概念模型？以及为什么要需要概念模型？

概念模型可以定义为由概念及其关系组成的模型。
概念模型是在绘制 UML 图之前的第一步。它有助于理解现实世界中的实体以及它们如何相互交互。

由于 UML 描述了实时系统，因此创建概念模型然后逐步进行非常重要。可以通过学习以下三个主要元素来掌握 UML 的概念模型：

UML 构建块
连接构建块的规则
UML 的通用机制

面向对象的概念

UML 可以被描述为面向对象 (OO) 分析和设计的继承者。

一个对象包含数据和控制数据的的方法。数据表示对象的状态。类描述一个对象，它们也形成一个层次结构来模拟现实世界系统。层次结构表示为继承，类也可以根据需要以不同的方式关联。

对象是我们周围存在的现实世界实体，抽象、封装、继承和多态等基本概念都可以用 UML 表示。

UML 足够强大，可以表示面向对象分析和设计中存在的所有概念。UML 图仅面向对象概念的表示。因此，在学习 UML 之前，详细了解 OO 概念变得很重要。

以下是面向对象世界的一些基本概念：

对象 - 对象表示实体和基本构建块。
类 - 类是对象的蓝图。
抽象 - 抽象表示现实世界实体的行为。
封装 - 封装是将数据绑定在一起并将其隐藏在外部世界之外的机制。
继承 - 继承是从现有类创建新类的机制。
多态 - 它定义了以不同形式存在的机制。

OO 分析与设计

OO 可以定义为调查，更具体地说，它是对对象的调查。设计意味着已识别对象的协作。

因此，了解 OO 分析和设计概念非常重要。OO 分析的最重要目的是识别要设计的系统的对象。此分析也针对现有系统进行。现在，只有当我们能够以能够识别对象的方式开始思考时，才能进行有效的分析。识别对象后，识别它们的关系，最后生成设计。

OO 分析和设计的目的可以描述为：

识别系统的对象。
识别它们之间的关系。
进行设计，可以使用 OO 语言将其转换为可执行文件。

在三个基本步骤中应用和实现了 OO 概念。这些步骤可以定义为

OO Analysis → OO Design → OO implementation using OO languages

以上三点可以详细描述为：

在 OO 分析期间，最重要的是识别对象并以正确的方式描述它们。如果这些对象被有效地识别，那么下一步的设计工作就很容易了。应该用职责来识别对象。职责是对象执行的功能。每个对象都有一些要执行的职责。当这些职责协作时，系统的目的就实现了。
第二阶段是 OO 设计。在此阶段，重点放在需求及其满足上。在此阶段，对象根据其预期关联进行协作。关联完成后，设计也完成了。
第三阶段是 OO 实现。在此阶段，使用 Java、C++ 等 OO 语言实现设计。

UML 在 OO 设计中的作用

UML 是一种用于对软件和非软件系统建模的建模语言。尽管 UML 用于非软件系统，但重点是建模 OO 软件应用程序。迄今为止讨论的大多数 UML 图都用于建模不同的方面，例如静态、动态等。现在无论方面如何，工件都不过是对象。

如果我们查看类图、对象图、协作图、交互图，所有这些都将基本上基于对象进行设计。

因此，了解 OO 设计和 UML 之间的关系非常重要。OO 设计根据需要转换为 UML 图。在详细了解 UML 之前，应正确学习 OO 概念。完成 OO 分析和设计后，下一步就非常容易了。来自 OO 分析和设计的输入是 UML 图的输入。

UML - 构建块

由于 UML 描述了实时系统，因此创建概念模型然后逐步进行非常重要。可以通过学习以下三个主要元素来掌握 UML 的概念模型：

UML 构建块
连接构建块的规则
UML 的通用机制

本章描述了所有 UML 构建块。UML 的构建块可以定义为：

事物
关系
图

事物

事物是 UML 最重要的构建块。事物可以是：

结构的
行为的
分组的
注释的

结构性事物

结构性事物定义了模型的静态部分。它们表示物理和概念元素。以下是结构性事物的简要描述。

类 - 类表示一组具有相似职责的对象。

接口 - 接口定义一组操作，这些操作指定类的职责。

协作 - 协作定义元素之间的交互。

用例 - 用例表示系统为特定目标执行的一组操作。

组件 - 组件描述系统的物理部分。

节点 - 节点可以定义为在运行时存在的物理元素。

行为性事物

行为性事物由 UML 模型的动态部分组成。以下是行为性事物：

交互 - 交互定义为由元素之间交换的一组消息组成的行为，以完成特定任务。

状态机 - 当对象在其生命周期中的状态很重要时，状态机很有用。它定义了对象响应事件而经历的状态序列。事件是导致状态变化的外部因素

分组事物

分组事物可以定义为将 UML 模型的元素组合在一起的机制。只有一个可用的分组事物：

包 - 包是唯一一个用于收集结构和行为事物的分组事物。

注释性事物

注释性事物可以定义为捕获 UML 模型元素的备注、描述和注释的机制。注意 - 它是唯一一个可用的注释性事物。注释用于呈现 UML 元素的注释、约束等。

关系

关系是 UML 的另一个最重要的构建块。它显示了元素如何相互关联，并且这种关联描述了应用程序的功能。

有四种可用的关系。

依赖

依赖关系是两个事物之间的一种关系，其中一个元素的变化也会影响另一个元素。

关联

关联基本上是一组连接UML模型元素的链接。它还描述了有多少对象参与了该关系。

泛化

泛化可以定义为一种将专门化元素与泛化元素连接起来的关系。它基本上描述了对象世界中的继承关系。

实现

实现可以定义为两个元素连接的关系。一个元素描述了一些未实现的职责，另一个元素实现它们。这种关系存在于接口的情况下。

UML图

UML图是整个讨论的最终输出。所有元素、关系都用于制作完整的UML图，并且该图表示一个系统。

UML图的视觉效果是整个过程中最重要的部分。所有其他元素都用于使其完整。

UML包括以下九种图，其详细信息将在后续章节中描述。

类图
对象图
用例图
序列图
协作图
活动图
状态图
部署图
组件图

UML - 架构

任何现实世界的系统都被不同的用户使用。用户可以是开发人员、测试人员、业务人员、分析师等等。因此，在设计系统之前，架构是考虑到不同的视角而构建的。最重要的是从不同查看者的角度可视化系统。我们理解得越好，我们就能更好地构建系统。

UML在定义系统的不同视角方面发挥着重要作用。这些视角包括：

设计
实现
流程
部署

中心是用例视图，它连接了这四个视图。用例表示系统的功能。因此，其他视角都与用例相关联。

系统的设计包括类、接口和协作。UML提供类图、对象图来支持这一点。

实现定义了组装在一起形成完整物理系统的组件。UML组件图用于支持实现视角。

流程定义了系统的流程。因此，与设计中使用的相同元素也用于支持此视角。

部署表示构成硬件的系统的物理节点。UML部署图用于支持此视角。

UML - 建模类型

区分UML模型非常重要。不同的图用于不同类型的UML建模。UML建模有三种重要类型。

结构建模

结构建模捕获系统的静态特征。它们包括以下内容：

类图
对象图
部署图
包图
复合结构图
组件图

结构模型表示系统的框架，并且此框架是所有其他组件存在的位置。因此，类图、组件图和部署图是结构建模的一部分。它们都表示元素以及组装它们的机制。

结构模型从不描述系统的动态行为。类图是最广泛使用的结构图。

行为建模

行为模型描述系统中的交互。它表示结构图之间的交互。行为建模显示了系统的动态特性。它们包括以下内容：

活动图
交互图
用例图

以上所有内容都显示了系统中动态流程的顺序。

架构建模

架构模型表示系统的整体框架。它包含系统的结构和行为元素。架构模型可以定义为整个系统的蓝图。包图属于架构建模。

UML - 基本符号

UML因其图形表示法而流行。我们都知道，UML用于可视化、指定、构建和记录软件和非软件系统的组件。因此，可视化是最重要的部分，需要理解和记住。

UML表示法是建模中最重要的元素。有效且恰当地使用表示法对于创建完整且有意义的模型非常重要。除非正确地描绘了模型的目的，否则该模型是无用的。

因此，应该从一开始就强调学习表示法。事物和关系有不同的表示法。UML图是使用事物和关系的表示法制作的。可扩展性是另一个重要的特性，它使UML更加强大和灵活。

本章详细描述了基本的UML表示法。这只是对第二章中讨论的UML构建块部分的扩展。

结构性事物

结构事物中使用的图形表示法在UML中使用最广泛。这些被认为是UML模型的名词。以下是结构事物的列表。

类
对象
接口
协作
用例
活动类
组件
节点

类表示法

UML类由下图表示。该图分为四个部分。

顶部部分用于命名类。
第二个部分用于显示类的属性。
第三部分用于描述类执行的操作。
第四部分是可选的，用于显示任何其他组件。

类用于表示对象。对象可以是任何具有属性和职责的事物。

对象表示法

对象的表示方式与类相同。唯一的区别是名称是带下划线的，如下面的图所示。

由于对象是类的实际实现，称为类的实例。因此，它与类的用法相同。

接口表示法

接口由一个圆圈表示，如下面的图所示。它有一个名称，通常写在圆圈下方。

接口用于描述不带实现的功能。接口就像一个模板，在其中定义不同的函数，而不是实现。当一个类实现接口时，它也会根据需要实现功能。

协作表示法

协作由一个虚线椭圆表示，如下面的图所示。它在椭圆内写有一个名称。

协作表示职责。通常，职责是一组。

用例表示法

用例表示为一个带有名称的椭圆。它可能包含其他职责。

用例用于捕获系统的较高级别功能。

参与者表示法

参与者可以定义为与系统交互的某些内部或外部实体。

参与者用于用例图中描述内部或外部实体。

初始状态表示法

初始状态定义为显示流程的开始。此表示法几乎用于所有图中。

初始状态表示法的用途是显示流程的起点。

最终状态表示法

最终状态用于显示流程的结束。此表示法也几乎用于所有图中以描述结束。

最终状态表示法的用途是显示流程的终止点。

活动类表示法

活动类看起来类似于带实线的类。活动类通常用于描述系统的并发行为。

活动类用于表示系统中的并发性。

组件表示法

UML中的组件在下图中以内部名称显示。可以在需要的地方添加其他元素。

组件用于表示制作UML图的系统的任何部分。

节点表示法

UML中的节点由一个正方形表示，如下面的图所示，带有名称。节点表示系统的物理组件。

节点用于表示系统的物理部分，例如服务器、网络等。

行为性事物

动态部分是UML中最重要的元素之一。UML具有一套强大的功能来表示软件和非软件系统的动态部分。这些功能包括交互和状态机。

交互可以分为两种类型：

顺序（由序列图表示）
协作（由协作图表示）

交互表示法

交互基本上是两个UML组件之间的消息交换。下图表示交互中使用的不同表示法。

交互用于表示系统组件之间的通信。

状态机表示法

状态机描述了组件在其生命周期中的不同状态。表示法在下面的图中描述。

状态机用于描述系统组件的不同状态。状态可以是活动、空闲或任何其他状态，具体取决于情况。

分组事物

组织UML模型是设计中最重要的方面之一。在UML中，只有一个可用于分组的元素，那就是包。

包表示法

包表示法如下面的图所示，用于包装系统的组件。

注释性事物

在任何图中，对不同元素及其功能的解释都非常重要。因此，UML具有注释表示法来支持此需求。

注释表示法

此表示法如下面的图所示。这些表示法用于提供系统必要的信息。

关系

除非正确描述了元素之间的关系，否则模型是不完整的。关系赋予UML模型正确的含义。以下是UML中可用的不同类型的关系。

依赖
关联
泛化
可扩展性

依赖关系表示法

依赖关系是UML元素中的一个重要方面。它描述了依赖元素和依赖方向。

依赖关系由一个虚线箭头表示，如下面的图所示。箭头表示独立元素，另一端表示依赖元素。

依赖关系用于表示系统中两个元素之间的依赖关系

关联表示法

关联描述了UML图中元素是如何关联的。简单来说，它描述了多少个元素参与了交互。

关联由一条带（不带）箭头的虚线表示。两端表示两个关联的元素，如下面的图所示。倍数也写在末端（1、* 等），以显示关联了多少个对象。

关联用于表示系统中两个元素之间的关系。

泛化表示法

泛化描述了面向对象世界的继承关系。它是父子关系。

泛化由一个带有空心箭头的箭头表示，如下面的图所示。一端表示父元素，另一端表示子元素。

泛化用于描述系统中两个元素的父子关系。

可扩展性表示法

所有语言（编程或建模）都有一些机制来扩展其功能，例如语法、语义等。UML还具有以下机制来提供可扩展性功能。

构造型（表示新元素）
标记值（表示新属性）
约束（表示边界）

可扩展性表示法用于增强语言的功能。它基本上是用于表示系统某些额外行为的附加元素。这些额外行为没有被标准的可用表示法覆盖。

UML - 标准图

在前面的章节中，我们讨论了UML的构建块和其他必要的元素。现在我们需要了解在哪里使用这些元素。

元素就像组件，可以以不同的方式关联起来构成完整的UML图，即所谓的图。因此，了解不同的图以在现实系统中应用这些知识非常重要。

任何复杂的系统，最好的理解方式就是绘制一些图表或图片。这些图表对我们的理解有更好的影响。如果我们环顾四周，就会意识到图表并不是一个新概念，而是在不同行业的不同形式中被广泛使用。

我们准备UML图是为了以更好、更简单的方式理解系统。单个图不足以涵盖系统的所有方面。UML定义了各种类型的图来涵盖系统的大部分方面。

你也可以创建自己的图表集来满足你的需求。图表通常以增量和迭代的方式制作。

图表主要分为两大类，并且再次细分为子类别：

结构图
行为图

结构图

结构图表示系统的静态方面。这些静态方面表示构成主要结构并因此稳定的图表部分。

这些静态部分由类、接口、对象、组件和节点表示。四种结构图如下：

类图
对象图
组件图
部署图

类图

类图是UML中最常用的图。类图由类、接口、关联和协作组成。类图基本上表示系统的面向对象视图，其本质是静态的。

活动类用于在类图中表示系统的并发性。

类图表示系统的面向对象特性。因此，它通常用于开发目的。这是系统构建时使用最广泛的图。

对象图

对象图可以描述为类图的一个实例。因此，这些图更接近于我们实现系统的现实场景。

对象图是一组对象及其关系，就像类图一样。它们也表示系统的静态视图。

对象图的用法类似于类图，但它们用于从实践角度构建系统的原型。

组件图

组件图表示一组组件及其关系。这些组件由类、接口或协作组成。组件图表示系统的实现视图。

在设计阶段，系统的软件构件（类、接口等）根据它们的关系被安排成不同的组。现在，这些组被称为组件。

最后，可以说组件图用于可视化实现。

部署图

部署图是一组节点及其关系。这些节点是部署组件的物理实体。

部署图用于可视化系统的部署视图。这通常由部署团队使用。

注意 - 如果仔细观察上述描述和用法，就会很清楚所有图表之间都存在某种关系。组件图依赖于类、接口等，这些是类/对象图的一部分。同样，部署图依赖于用于创建组件图的组件。

行为图

任何系统都可以具有两个方面，即静态和动态。因此，当这两个方面都被完全覆盖时，模型才被认为是完整的。

行为图基本上捕获系统的动态方面。动态方面可以进一步描述为系统的变化/移动部分。

UML具有以下五种类型的行为图：

用例图
序列图
协作图
状态图
活动图

用例图

用例图是一组用例、参与者及其关系。它们表示系统的用例视图。

用例表示系统的特定功能。因此，用例图用于描述功能之间及其内部/外部控制器的关系。这些控制器被称为参与者。

顺序图

顺序图是一种交互图。从名称上可以清楚地看出，该图处理一些序列，即从一个对象到另一个对象的消息序列。

系统组件之间的交互对于实现和执行角度来说非常重要。顺序图用于可视化系统中执行特定功能的调用序列。

协作图

协作图是交互图的另一种形式。它表示系统的结构组织以及发送/接收的消息。结构组织由对象和链接组成。

协作图的目的与顺序图类似。但是，协作图的具体目的是可视化对象的组织及其交互。

状态图

任何实时系统都期望对某种内部/外部事件做出反应。这些事件导致系统的状态变化。

状态图用于表示系统的事件驱动状态变化。它基本上描述了类、接口等的状态变化。

状态图用于可视化系统对内部/外部因素的反应。

活动图

活动图描述了系统中的控制流。它由活动和链接组成。流可以是顺序的、并发的或分支的。

活动只不过是系统函数。准备了大量的活动图来捕获系统中的整个流程。

活动图用于可视化系统中的控制流。准备它是为了了解系统在执行时将如何工作。

注意 - 系统的动态特性非常难以捕获。UML提供了从不同角度捕获系统动态特性的功能。顺序图和协作图是同构的，因此可以在不丢失任何信息的情况下相互转换。状态图和活动图也是如此。

UML - 类图

类图是静态图。它表示应用程序的静态视图。类图不仅用于可视化、描述和记录系统的不同方面，还用于构建软件应用程序的可执行代码。

类图描述了类的属性和操作，以及对系统施加的约束。类图广泛用于面向对象系统的建模，因为它们是唯一可以与面向对象语言直接映射的UML图。

类图显示了类、接口、关联、协作和约束的集合。它也被称为结构图。

类图的目的

类图的目的是对应用程序的静态视图进行建模。类图是唯一可以与面向对象语言直接映射的图，因此在构建时被广泛使用。

像活动图、顺序图这样的UML图只能给出应用程序的顺序流，但是类图有所不同。它是编码社区中最流行的UML图。

类图的目的可以概括为：

分析和设计应用程序的静态视图。
描述系统的职责。
组件和部署图的基础。
正向和反向工程。

如何绘制类图？

类图是用于构建软件应用程序的最流行的UML图。学习类图的绘制过程非常重要。

类图在绘制时需要考虑许多属性，但这里将从顶层视图考虑该图。

类图基本上是系统静态视图的图形表示，并表示应用程序的不同方面。类图的集合表示整个系统。

绘制类图时应记住以下几点：

类图的名称应具有意义，以描述系统的方面。
应提前识别每个元素及其关系。
应明确识别每个类的职责（属性和方法）。
对于每个类，应指定最少的属性，因为不必要的属性会使图变得复杂。
在需要时使用注释来描述图的某些方面。在绘制结束时，它应该让开发人员/编码人员易于理解。
最后，在制作最终版本之前，应在普通纸上绘制图表，并尽可能多次重新绘制以使其正确。

下图是应用程序订单系统的示例。它描述了整个应用程序的特定方面。

首先，订单和客户被识别为系统的两个元素。它们具有一对多关系，因为一个客户可以有多个订单。
Order类是一个抽象类，它有两个具体类（继承关系）SpecialOrder和NormalOrder。
两个继承类都具有与Order类相同的属性。此外，它们还具有其他功能，如dispatch()和receive()。

下图是在考虑上述所有要点的情况下绘制的。

类图在哪里使用？

类图是静态图，用于对系统的静态视图进行建模。静态视图描述了系统的词汇表。

类图也被认为是组件和部署图的基础。类图不仅用于可视化系统的静态视图，还用于构建任何系统的正向和反向工程的可执行代码。

通常，UML图不会与任何面向对象编程语言直接映射，但类图是一个例外。

类图清晰地展示了与面向对象语言（如 Java、C++ 等）的映射关系。从实践经验来看，类图通常用于构建目的。

简而言之，类图用于：

描述系统的静态视图。
展示静态视图中元素之间的协作关系。
描述系统执行的功能。
使用面向对象语言构建软件应用程序。

UML - 对象图

对象图是从类图派生出来的，因此对象图依赖于类图。

对象图表示类图的一个实例。类图和对象图的基本概念相似。对象图也表示系统的静态视图，但这种静态视图是系统在特定时刻的快照。

对象图用于呈现一组对象及其关系作为实例。

对象图的目的

要将对象图在实践中应用，必须清楚地理解其目的。对象图的目的与类图类似。

区别在于，类图表示一个由类及其关系组成的抽象模型。然而，对象图表示特定时刻的一个实例，其本质是具体的。

这意味着对象图更接近实际系统的行为。其目的是捕捉系统在特定时刻的静态视图。

对象图的目的可以概括为：

正向和反向工程。
系统的对象关系
交互的静态视图。
从实践角度理解对象行为及其关系

如何绘制对象图？

我们已经讨论过，对象图是类图的一个实例。这意味着对象图包含类图中使用的实例。

因此，这两个图都由相同的基本元素组成，但形式不同。在类图中，元素以抽象形式表示蓝图，而在对象图中，元素以具体形式表示现实世界中的对象。

为了捕捉特定的系统，类图的数量是有限的。但是，如果我们考虑对象图，则可以拥有无限数量的实例，这些实例本质上是唯一的。只有那些对系统有影响的实例才会被考虑。

从以上讨论可以看出，单个对象图无法捕捉所有必要的实例，或者说无法指定系统的所有对象。因此，解决方案是：

首先，分析系统并确定哪些实例具有重要的数据和关联。
其次，只考虑那些能够覆盖功能的实例。
第三，进行一些优化，因为实例的数量是无限的。

在绘制对象图之前，应记住并清楚地理解以下几点：

对象图由对象组成。
对象图中的链接用于连接对象。
对象和链接是用于构建对象图的两个元素。

在此之后，在开始构建图之前需要确定以下几点：

对象图应具有有意义的名称以指示其目的。
识别最重要的元素。
阐明对象之间的关联关系。
捕获不同元素的值以包含在对象图中。
在需要更多清晰度的点添加适当的注释。

下图是一个对象图的示例。它表示我们在类图章节中讨论过的订单管理系统。下图是系统在购买特定时间的实例。它包含以下对象。

客户
订单
特殊订单
普通订单

现在，客户对象 (C) 与三个订单对象 (O1、O2 和 O3) 相关联。这些订单对象与特殊订单和普通订单对象 (S1、S2 和 N1) 相关联。客户在所考虑的特定时间拥有以下三个订单，订单编号分别为 12、32 和 40。

客户将来可以增加订单数量，在这种情况下，对象图将反映出来。如果观察订单、特殊订单和普通订单对象，您会发现它们具有一些值。

对于订单，其值为 12、32 和 40，这意味着对象在特定时刻（此处将购买完成时的特定时间视为时刻）捕获实例时具有这些值。

特殊订单和普通订单对象也是如此，它们分别具有 20、30 和 60 的订单数量。如果考虑不同的购买时间，则这些值将相应地改变。

下图是在考虑上述所有要点后绘制的对象图。

在哪里使用对象图？

可以将对象图想象成正在运行的系统在特定时刻的快照。让我们以正在运行的火车为例。

现在，如果您拍摄正在运行的火车的快照，您会发现它的静态图片，其中包含以下内容：

一个特定的状态，即正在运行。
特定数量的乘客，如果在不同的时间拍摄快照，这个数量将发生变化。

在这里，我们可以想象正在运行的火车的快照是一个具有上述值的对象。对于任何现实生活中简单或复杂的系统，情况都是如此。

简而言之，可以说对象图用于：

创建系统的原型。
逆向工程。
建模复杂的数据结构。
从实践角度理解系统。

UML - 组件图

组件图在性质和行为方面有所不同。组件图用于对系统的物理方面进行建模。现在问题是，这些物理方面是什么？物理方面是指可执行文件、库、文件、文档等驻留在节点中的元素。

组件图用于可视化系统中组件的组织和关系。这些图还用于创建可执行系统。

组件图的目的

组件图是 UML 中一种特殊的图。其目的也与迄今为止讨论的所有其他图不同。它不描述系统功能，而是描述用于实现这些功能的组件。

因此，从这个角度来看，组件图用于可视化系统中的物理组件。这些组件包括库、包、文件等。

组件图也可以描述为系统的静态实现视图。静态实现表示特定时刻组件的组织方式。

单个组件图无法表示整个系统，而是使用一组图来表示整体。

组件图的目的可以概括为：

可视化系统的组件。
通过使用正向和反向工程构建可执行文件。
描述组件的组织和关系。

如何绘制组件图？

组件图用于描述系统的物理构件。这些构件包括文件、可执行文件、库等。

此图的目的不同。组件图在应用程序的实现阶段使用。但是，它会提前准备好以可视化实现细节。

最初，系统使用不同的 UML 图进行设计，然后当构件准备就绪时，使用组件图来了解实现情况。

此图非常重要，因为没有它，应用程序就无法有效地实现。精心准备的组件图对于其他方面（如应用程序性能、维护等）也很重要。

在绘制组件图之前，需要清楚地识别以下构件：

系统中使用的文件。
与应用程序相关的库和其他构件。
构件之间的关系。

识别完构件后，需要注意以下几点。

使用有意义的名称来标识要绘制图的组件。
在使用工具生成之前，先在脑海中进行布局。
使用注释来阐明重要要点。

以下是订单管理系统的组件图。此处，构件为文件。该图显示了应用程序中的文件及其关系。实际上，组件图还包含 dll、库、文件夹等。

在下图中，识别了四个文件并生成了它们之间的关系。组件图不能直接与迄今为止讨论的其他 UML 图匹配，因为它用于完全不同的目的。

下图是在考虑上述所有要点后绘制的组件图。

在哪里使用组件图？

我们已经描述过，组件图用于可视化系统的静态实现视图。组件图是用于不同目的的 UML 图的特殊类型。

这些图显示了系统的物理组件。为了阐明这一点，我们可以说组件图描述了系统中组件的组织方式。

组织可以进一步描述为组件在系统中的位置。这些组件以特殊的方式组织以满足系统需求。

正如我们已经讨论过的，这些组件包括库、文件、可执行文件等。在实现应用程序之前，需要组织这些组件。这种组件组织也作为项目执行的一部分单独设计。

组件图从实现的角度来看非常重要。因此，应用程序的实现团队应该具备组件细节的正确知识。

组件图可用于：

对系统的组件进行建模。
对数据库模式进行建模。
对应用程序的可执行文件进行建模。
对系统的源代码进行建模。

UML - 部署图

部署图用于可视化系统的物理组件拓扑，软件组件部署在其中。

部署图用于描述系统的静态部署视图。部署图由节点及其关系组成。

部署图的目的

术语“部署”本身描述了图的目的。部署图用于描述硬件组件，软件组件部署在其中。组件图和部署图密切相关。

组件图用于描述组件，而部署图则显示它们如何在硬件中部署。

UML 主要设计用于关注系统的软件构件。但是，这两个图是用于关注软件和硬件组件的特殊图。

大多数UML图用于处理逻辑组件，但部署图旨在关注系统的硬件拓扑结构。部署图由系统工程师使用。

部署图的目的可以描述为：

可视化系统的硬件拓扑结构。
描述用于部署软件组件的硬件组件。
描述运行时处理节点。

如何绘制部署图？

部署图表示系统的部署视图。它与组件图相关，因为组件是使用部署图部署的。部署图由节点组成。节点只不过是用于部署应用程序的物理硬件。

部署图对系统工程师很有用。一个有效的部署图非常重要，因为它控制以下参数：

性能
可扩展性
可维护性
可移植性

在绘制部署图之前，应识别以下工件：

节点
节点之间的关系

下面是一个示例部署图，用于提供订单管理系统部署视图的概念。这里，我们显示节点如下：

监控器
调制解调器
缓存服务器
服务器

假设应用程序是一个基于Web的应用程序，它使用服务器1、服务器2和服务器3部署在集群环境中。用户通过互联网连接到应用程序。控制流从缓存服务器流向集群环境。

以下部署图是在考虑上述所有要点的情况下绘制的。

在哪里使用部署图？

部署图主要由系统工程师使用。这些图用于描述物理组件（硬件）、它们的分布和关联。

部署图可以被视为软件组件驻留其上的硬件组件/节点。

软件应用程序是为了模拟复杂的业务流程而开发的。有效的软件应用程序不足以满足业务需求。业务需求可以描述为支持越来越多的用户、快速响应时间等的需求。

为了满足这些类型的需求，应高效且经济地设计硬件组件。

如今，软件应用程序的本质非常复杂。软件应用程序可以是独立的、基于Web的、分布式的、基于大型机的等等。因此，高效地设计硬件组件非常重要。

部署图可用于：

对系统的硬件拓扑结构建模。
对嵌入式系统建模。
对客户机/服务器系统的硬件细节建模。
对分布式应用程序的硬件细节建模。
用于正向和反向工程。

UML - 用例图

为了对系统进行建模，最重要的方面是捕获动态行为。动态行为是指系统运行/操作时的行为。

仅有静态行为不足以对系统进行建模，动态行为比静态行为更重要。在UML中，有五个图可用于对动态特性进行建模，用例图就是其中之一。现在，既然我们必须讨论用例图本质上是动态的，那么应该有一些内部或外部因素来进行交互。

这些内部和外部代理称为参与者。用例图由参与者、用例及其关系组成。该图用于对应用程序的系统/子系统进行建模。单个用例图捕获系统的一个特定功能。

因此，为了对整个系统进行建模，使用了多个用例图。

用例图的目的

用例图的目的是捕获系统的动态方面。但是，这个定义过于笼统，无法描述目的，因为其他四个图（活动图、序列图、协作图和状态图）也有相同的目的。我们将研究一些具体目的，这将使它与其他四个图区分开来。

用例图用于收集系统的需求，包括内部和外部影响。这些需求大多是设计需求。因此，当分析系统以收集其功能时，会准备用例并识别参与者。

初始任务完成后，会对用例图进行建模以呈现外部视图。

简而言之，用例图的目的可以概括如下：

用于收集系统的需求。
用于获取系统的外部视图。
识别影响系统的外部和内部因素。
显示需求和参与者之间的交互。

如何绘制用例图？

用例图被认为是系统的高级需求分析。当分析系统的需求时，功能将在用例中捕获。

可以说，用例只不过是以有组织的方式编写的系统功能。与用例相关的第二件事是参与者。参与者可以定义为与系统交互的任何事物。

参与者可以是人类用户、一些内部应用程序，或者可能是某些外部应用程序。当我们计划绘制用例图时，应该识别以下项目。

要表示为用例的功能
参与者
用例和参与者之间的关系。

用例图用于捕获系统的功能需求。识别上述项目后，我们必须使用以下指南来绘制有效的用例图

用例的名称非常重要。应选择名称以使其能够识别执行的功能。
为参与者提供合适的名称。
在图中清楚地显示关系和依赖关系。
不要尝试包含所有类型的关系，因为图的主要目的是识别需求。
在需要时使用注释来澄清一些要点。

下面是一个示例用例图，表示订单管理系统。因此，如果我们查看该图，我们将发现三个用例（订单、特殊订单和普通订单）和一个参与者，即客户。

特殊订单和普通订单用例是从订单用例扩展的。因此，它们具有扩展关系。另一个要点是识别系统边界，如图片所示。参与者客户位于系统外部，因为它是系统的外部用户。

在哪里使用用例图？

正如我们已经讨论的那样，UML中有五个图用于对系统的动态视图进行建模。现在，每个模型都有一些特定的用途。实际上，这些特定的用途是正在运行的系统的不同角度。

要了解系统的动态特性，我们需要使用不同类型的图。用例图就是其中之一，其特定目的是收集系统需求和参与者。

用例图指定系统的事件及其流程。但是用例图从未描述它们是如何实现的。用例图可以想象成一个黑盒，只有黑盒的输入、输出和功能是已知的。

这些图在非常高的设计级别使用。这种高级设计会反复细化，以获得系统的完整和实用图景。结构良好的用例还描述了先决条件、后置条件和异常。这些额外元素用于在执行测试时创建测试用例。

虽然用例不是正向和反向工程的良好候选者，但它们仍然以略微不同的方式用于进行正向和反向工程。反向工程也是如此。用例图的使用方式有所不同，以使其适合反向工程。

在正向工程中，用例图用于创建测试用例；在反向工程中，用例图用于从现有应用程序准备需求详细信息。

用例图可用于：

需求分析和高级设计。
对系统的上下文建模。
逆向工程。
正向工程。

UML - 交互图

从术语“交互”可以清楚地看出，该图用于描述模型中不同元素之间的一些类型的交互。这种交互是系统动态行为的一部分。

这种交互行为在UML中由两个图表示，称为序列图和协作图。这两个图的基本目的是相似的。

序列图强调消息的时间顺序，协作图强调发送和接收消息的对象的结构组织。

交互图的目的

交互图的目的是可视化系统的交互行为。可视化交互是一项困难的任务。因此，解决方案是使用不同类型的模型来捕获交互的不同方面。

序列图和协作图用于捕获动态特性，但从不同的角度出发。

交互图的目的是：

捕获系统的动态行为。
描述系统中的消息流。
描述对象的结构组织。
描述对象之间的交互。

如何绘制交互图？

正如我们已经讨论的那样，交互图的目的是捕获系统的动态方面。因此，为了捕获动态方面，我们需要了解什么是动态方面以及如何对其进行可视化。动态方面可以定义为系统在特定时刻的快照。

UML中有两种类型的交互图。一种是序列图，另一种是协作图。序列图捕获从一个对象到另一个对象的消息流的时间顺序，而协作图描述参与消息流的系统中对象的组织。

在绘制交互图之前，需要清楚地识别以下事项

参与交互的对象。
对象之间的消息流。
消息流的顺序。
对象组织。

以下是两个对订单管理系统进行建模的交互图。第一个图是序列图，第二个是协作图

序列图

序列图有四个对象（客户、订单、特殊订单和普通订单）。

下图显示了特殊订单对象的消息序列，在普通订单对象的情况下也可以使用相同的消息序列。了解消息流的时间顺序非常重要。消息流只不过是对象的方法调用。

第一个调用是sendOrder ()，它是Order 对象的方法。下一个调用是confirm ()，它是SpecialOrder对象的方法，最后一个调用是Dispatch ()，它是SpecialOrder对象的方法。下图主要描述了从一个对象到另一个对象的方法调用，这也是系统运行时的实际场景。

协作图

第二个交互图是协作图。它显示了如下所示的对象组织。在协作图中，方法调用序列由某种编号技术指示。数字表示方法如何一个接一个地被调用。我们以相同的订单管理系统来描述协作图。

方法调用类似于顺序图。但是，区别在于顺序图没有描述对象组织，而协作图显示了对象组织。

在这两个图之间进行选择时，重点放在需求类型上。如果时间顺序很重要，则使用顺序图。如果需要组织，则使用协作图。

在哪里使用交互图？

我们已经讨论过交互图用于描述系统的动态特性。现在，我们将深入了解这些图的实际应用场景。为了理解实际应用，我们需要了解顺序图和协作图的基本性质。

这两个图的主要目的是相似的，因为它们都用于捕获系统的动态行为。但是，具体目的更重要，需要澄清和理解。

顺序图用于捕获从一个对象到另一个对象的消息流顺序。协作图用于描述参与交互的对象的结构组织。单个图不足以描述整个系统的动态方面，因此使用一组图来整体捕获它。

当我们想要理解消息流和结构组织时，会使用交互图。消息流表示从一个对象到另一个对象的控制流序列。结构组织表示系统中元素的可视化组织。

交互图可用于 -

通过时间序列对控制流进行建模。
通过结构组织对控制流进行建模。
用于正向工程。
用于逆向工程。

UML - 状态图

图的名称本身就阐明了图的目的和其他细节。它描述了系统中组件的不同状态。状态特定于系统的组件/对象。

状态图描述了一个状态机。状态机可以定义为一个机器，它定义了对象的不同的状态，并且这些状态受外部或内部事件控制。

下一章解释的活动图是一种特殊的状态图。由于状态图定义了状态，因此它用于对对象的生存期进行建模。

状态图的目的

状态图是用于对系统的动态特性进行建模的五个UML图之一。它们定义了对象在其生命周期中的不同状态，并且这些状态会因事件而改变。状态图可用于对反应式系统进行建模。反应式系统可以定义为响应外部或内部事件的系统。

状态图描述了从一个状态到另一个状态的控制流。状态定义为对象存在的一种条件，并且当触发某些事件时，它会发生变化。状态图最重要的目的是对对象从创建到终止的生命周期进行建模。

状态图也用于系统的正向和逆向工程。但是，主要目的是对反应式系统进行建模。

以下是使用状态图的主要目的 -

对系统的动态方面进行建模。
对反应式系统的生命周期进行建模。
描述对象在其生命周期中的不同状态。
定义状态机来对对象的状态进行建模。

如何绘制状态图？

状态图用于描述不同对象在其生命周期中的状态。重点放在某些内部或外部事件发生时状态的变化上。这些对象的状态对于分析和准确实现它们非常重要。

状态图对于描述状态非常重要。状态可以识别为对象在发生特定事件时的条件。

在绘制状态图之前，我们应该明确以下几点 -

确定要分析的重要对象。
确定状态。
确定事件。

以下是一个状态图示例，其中分析了Order 对象的状态

第一个状态是空闲状态，从这里开始流程。接下来的状态是针对诸如发送请求、确认请求和调度订单之类的事件而到达的。这些事件负责订单对象的状态变化。

在对象（此处为订单对象）的生命周期中，它会经历以下状态，并且可能存在一些异常退出。这种异常退出可能是由于系统中的一些问题引起的。当整个生命周期完成后，它被认为是一个完整的交易，如下面的图所示。对象初始状态和最终状态也显示在下图中。

在哪里使用状态图？

从以上讨论中，我们可以定义状态图的实际应用。状态图用于对系统的动态方面进行建模，就像本教程中讨论的其他四个图一样。但是，它具有一些用于建模动态特性的区别特征。

状态图定义了组件的状态，并且这些状态变化本质上是动态的。它的具体目的是定义由事件触发的状态变化。事件是影响系统的内部或外部因素。

状态图用于对状态以及作用于系统的事件进行建模。在实现系统时，明确对象在其生命周期中的不同状态非常重要，状态图用于此目的。当这些状态和事件被识别后，它们被用来对其进行建模，并且这些模型在系统实现过程中被使用。

如果我们深入研究状态图的实际实现，那么它主要用于分析受事件影响的对象状态。这种分析有助于理解系统在执行过程中的行为。

主要用途可以描述为 -

对系统的对象状态进行建模。
对反应式系统进行建模。反应式系统由反应式对象组成。
识别导致状态变化的事件。
正向和反向工程。

UML - 活动图

活动图是UML中另一个重要的图，用于描述系统的动态方面。

活动图基本上是一个流程图，用于表示从一个活动到另一个活动的流程。活动可以描述为系统的操作。

控制流从一个操作绘制到另一个操作。此流可以是顺序的、分支的或并发的。活动图通过使用不同的元素（如 fork、join 等）来处理所有类型的流控制。

活动图的目的

活动图的基本目的与其他四个图相似。它捕获系统的动态行为。其他四个图用于显示从一个对象到另一个对象的消息流，但活动图用于显示从一个活动到另一个活动的消息流。

活动是系统的一个特定操作。活动图不仅用于可视化系统的动态特性，还用于通过使用正向和逆向工程技术构建可执行系统。活动图中唯一缺少的是消息部分。

它没有显示从一个活动到另一个活动的消息流。活动图有时被认为是流程图。尽管图表看起来像流程图，但它们不是。它显示了不同的流程，例如并行、分支、并发和单个流程。

活动图的目的可以描述为 -

绘制系统的活动流程。
描述从一个活动到另一个活动的序列。
描述系统的并行、分支和并发流程。

如何绘制活动图？

活动图主要用作流程图，它包含系统执行的活动。活动图并不完全是流程图，因为它们具有一些额外的功能。这些附加功能包括分支、并行流、泳道等。

在绘制活动图之前，我们必须清楚地了解活动图中使用的元素。活动图的主要元素是活动本身。活动是系统执行的功能。在识别活动后，我们需要了解它们如何与约束和条件相关联。

在绘制活动图之前，我们应该识别以下元素 -

活动
关联
条件
约束

一旦识别出上述参数，我们就需要对整个流程进行心理布局。然后将此心理布局转换为活动图。

以下是一个订单管理系统的活动图示例。在图中，识别了四个活动，这些活动与条件相关联。应该清楚地理解一个重要点，即活动图不能完全与代码匹配。活动图旨在了解活动的流程，主要由业务用户使用。

下图是用四个主要活动绘制的 -

客户发送订单
接收订单
确认订单
分发订单

在收到订单请求后，会执行条件检查以检查订单是普通订单还是特殊订单。在识别订单类型后，执行分发活动，并将其标记为流程的结束。

活动图在哪里使用？

活动图的基本用法与其他四种UML图类似。其具体用法是模拟从一个活动到另一个活动的控制流。这种控制流不包括消息。

活动图适用于模拟系统的活动流程。一个应用程序可以有多个系统。活动图还捕获这些系统并描述从一个系统到另一个系统的流程。这种特定用法在其他图中不可用。这些系统可以是数据库、外部队列或任何其他系统。

我们现在将研究活动图的实际应用。从以上讨论可以看出，活动图是从一个非常高的层次绘制的。因此，它提供了系统的**高层视图**。这种高层视图主要面向业务用户或任何其他非技术人员。

此图用于模拟活动，这些活动只不过是业务需求。该图对业务理解的影响大于对实现细节的影响。

活动图可用于 -

使用活动建模工作流。
建模业务需求。
对系统功能的高级理解。
在后期调查业务需求。

打印页面