- UML教程
- UML - 主页
- UML - 概述
- UML - 构建块
- UML-架构
- UML - 建模类型
- UML - 基本符号
- UML - 标准图
- UML - 类图
- UML - 对象图
- UML - 组件图
- UML - 部署图
- UML - 用例图
- UML - 交互图
- UML - 状态图
- UML - 活动图
- UML - 总结
- UML 2.0 概述
- UML 2.0 - 概述
- UML 有用资源
- UML - 有用的资源
- UML-知识测试
- 公用事业
- UML - 工具和实用程序
- UML - 讨论
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 概念就变得很重要。
以下是面向对象世界的一些基本概念 -
对象- 对象代表一个实体和基本构建块。
类- 类是对象的蓝图。
抽象- 抽象代表现实世界实体的Behave。
封装- 封装是将数据绑定在一起并向外界隐藏它们的机制。
继承- 继承是从现有类创建新类的机制。
多态性- 它定义了以不同形式存在的机制。
面向对象分析与设计
OO可以定义为一种调查，更具体地说，是对对象的调查。设计意味着已识别对象的协作。
因此，理解OO分析和设计概念非常重要。OO 分析最重要的目的是识别要设计的系统的对象。此分析也是针对现有系统进行的。现在，只有当我们能够开始以可识别对象的方式进行思考时，才有可能进行有效的分析。识别对象后，确定它们之间的关系，最后产生设计。
OO 分析和设计的目的可以描述为 -
识别系统的对象。
确定他们的关系。
进行设计，可以使用 OO 语言将其转换为可执行文件。
应用和实现面向对象概念需要三个基本步骤。步骤可以定义为
OO Analysis → OO Design → OO implementation using OO languages
上述三点可以详细描述为 -
在面向对象分析中，最重要的目的是识别对象并以适当的方式描述它们。如果这些对象能够被有效地识别，那么接下来的设计工作就很容易了。应确定对象和职责。职责是对象执行的功能。每个对象都有某种类型的要执行的职责。当这些职责相互协作时，系统的目的就实现了。
第二阶段是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 最重要的构建块。事情可以是 -
- 结构性
- Behave的
- 分组
- 注释性的
结构性事物
结构性事物定义了模型的静态部分。它们代表物理和概念元素。以下是结构性事物的简要描述。
类 -类表示一组具有相似职责的对象。
接口 -接口定义了一组操作，它们指定了类的职责。
协作 -协作定义了元素之间的交互。
用例 -用例表示系统为特定目标执行的一组操作。
组件 -组件描述系统的物理部分。
节点 -节点可以定义为运行时存在的物理元素。
Behave事物
Behave事物由 UML 模型的动态部分组成。以下是Behave方面的事情 -
交互 -交互被定义为一种Behave，由元素之间交换的一组消息组成，以完成特定任务。
状态机-当对象在其生命周期中的状态很重要时，状态机非常有用。它定义了对象响应事件所经历的状态序列。事件是导致状态变化的外部因素
将事物分组
可以将事物分组定义为将 UML 模型的元素分组在一起的机制。只有一种可用的分组 -
包 -包是唯一可用于收集结构和Behave事物的分组事物。
注释性事物
注释性事物可以定义为一种捕获 UML 模型元素的注释、描述和注释的机制。注意- 这是唯一可用的注释性内容。注释用于呈现 UML 元素的注释、约束等。
关系
关系是 UML 的另一个最重要的构建块。它显示了元素如何相互关联，并且这种关联描述了应用程序的功能。
有四种可用的关系。
依赖性
依赖性是两个事物之间的关系，其中一个元素的变化也会影响另一个元素。
协会
关联基本上是连接 UML 模型元素的一组链接。它还描述了有多少对象参与该关系。
概括
泛化可以定义为将专门元素与泛化元素连接起来的关系。它基本上描述了对象世界中的继承关系。
实现
实现可以定义为两个元素相互连接的关系。一个元素描述了一些尚未实现的职责，而另一个元素则实现了它们。在接口的情况下存在这种关系。
UML图
UML 图是整个讨论的最终输出。所有的元素、关系都被用来制作一个完整的UML图，并且该图代表了一个系统。
UML图的视觉效果是整个过程中最重要的部分。所有其他元素都用于使其完整。
UML包括以下九个图，其详细信息将在后续章节中描述。
- 类图
- 对象图
- 用例图
- 时序图
- 协作图
- 活动图
- 状态图
- 部署图
- 元件图
UML-架构
任何现实世界的系统都由不同的用户使用。用户可以是开发人员、测试人员、业务人员、分析师等等。因此，在设计系统之前，架构是从不同的角度考虑的。最重要的部分是从不同观看者的角度可视化系统。我们了解得越多，我们就能更好地构建系统。
UML 在定义系统的不同视角方面发挥着重要作用。这些观点是 -
- 设计
- 执行
- 过程
- 部署
中心是连接所有这四个的用例视图。用例代表系统的功能。因此，其他观点与用例相关。
系统的设计由类、接口和协作组成。UML 提供了类图、对象图来支持这一点。
实现定义了组装在一起形成完整物理系统的组件。UML 组件图用于支持实现视角。
流程定义了系统的流程。因此，设计中使用的相同元素也用于支持这一观点。
部署代表构成硬件的系统的物理节点。UML 部署图用于支持这一观点。
UML - 建模类型
区分UML模型非常重要。不同类型的 UML 建模使用不同的图。UML 建模分为三种重要类型。
结构建模
结构建模捕获系统的静态特征。它们包括以下内容 -
- 类图
- 对象图
- 部署图
- 封装图
- 复合结构图
- 元件图
结构模型代表系统的框架，这个框架是所有其他组件存在的地方。因此，类图、组件图和部署图是结构建模的一部分。它们都代表了元素和组装它们的机制。
结构模型从不描述系统的动态Behave。类图是应用最广泛的结构图。
Behave建模
Behave模型描述了系统中的交互。它表示结构图之间的相互作用。Behave建模显示了系统的动态本质。它们包括以下内容 -
- 活动图
- 交互图
- 用例图
以上所有内容都显示了系统中流动的动态顺序。
建筑建模
架构模型代表了系统的整体框架。它包含系统的结构和Behave元素。架构模型可以定义为整个系统的蓝图。包图属于架构建模。
UML - 基本符号
UML 因其图表符号而广受欢迎。我们都知道 UML 用于可视化、指定、构建和记录软件和非软件系统的组件。因此，可视化是需要理解和记住的最重要的部分。
UML 符号是建模中最重要的元素。有效且适当地使用符号对于制作完整且有意义的模型非常重要。除非正确描述了其目的，否则该模型毫无用处。
因此，学习符号从一开始就应该受到重视。事物和关系可以使用不同的符号。UML 图是使用事物和关系的符号来制作的。可扩展性是使 UML 更加强大和灵活的另一个重要特性。
本章详细描述了基本的 UML 符号。这只是第二章中讨论的 UML 构建块部分的扩展。
结构性事物
结构事物中使用的图形符号在 UML 中使用最为广泛。这些被视为 UML 模型的名词。以下是结构性事物的列表。
- 课程
- 目的
- 界面
- 合作
- 使用案例
- 活跃课程
- 成分
- 节点
类别符号
UML类如下图所示。该图分为四个部分。
- 顶部部分用于命名类。
- 第二个用于显示类的属性。
- 第三部分用于描述该类执行的操作。
- 第四部分是可选的，用于显示任何附加组件。
类用于表示对象。对象可以是任何具有属性和责任的东西。
对象表示法
对象的表示方式与类相同。唯一的区别是名称带有下划线，如下图所示。
由于对象是类的实际实现，因此称为类的实例。因此，它与类具有相同的用法。
接口符号
接口用圆圈表示，如下图所示。它有一个名称，通常写在圆圈下方。
接口用于描述功能而不是实现。接口就像一个模板，您可以在其中定义不同的功能，而不是实现。当一个类实现接口时，它也根据要求实现功能。
协作符号
协作由点蚀表示，如下图所示。它有一个名字写在 eclipse 里面。
合作代表责任。一般来说，责任是在一个群体中的。
用例符号
用例被表示为一个包含名称的 Eclipse。它可能包含额外的责任。
用例用于捕获系统的高级功能。
演员符号
参与者可以定义为与系统交互的一些内部或外部实体。
参与者在用例图中用于描述内部或外部实体。
初始状态符号
初始状态被定义为显示进程的开始。几乎所有图表中都使用这种表示法。
初始状态表示法的用途是显示过程的起点。
最终状态符号
最终状态用于显示进程的结束。几乎所有图表中也都使用这种表示法来描述结尾。
最终状态表示法的用途是显示进程的终止点。
活动类表示法
活动类看起来类似于带有实线边框的类。活动类通常用于描述系统的并发Behave。
Active 类用于表示系统中的并发性。
组件符号
UML 中的一个组件如下图所示，里面有一个名称。可以根据需要添加其他元素。
组件用于表示为其制作 UML 图的系统的任何部分。
节点表示法
UML 中的节点由一个带有名称的方框表示，如下图所示。节点代表系统的物理组件。
节点用于表示系统的物理部分，例如服务器、网络等。
Behave事物
动态部分是 UML 中最重要的元素之一。UML 具有一组强大的功能来表示软件和非软件系统的动态部分。这些功能包括交互和状态机。
交互可以有两种类型 -
- 顺序（用顺序图表示）
- 协作（用协作图表示）
交互符号
交互基本上是两个 UML 组件之间的消息交换。下图表示交互中使用的不同符号。
交互用于表示系统组件之间的通信。
状态机符号
状态机描述了组件在其生命周期中的不同状态。下图描述了这些符号。
状态机用于描述系统组件的不同状态。根据具体情况，状态可以是活动的、空闲的或任何其他状态。
将事物分组
组织 UML 模型是设计中最重要的方面之一。在 UML 中，只有一个元素可用于分组，那就是包。
封装符号
包符号如下图所示，用于包装系统的组件。
注释性事物
在任何图中，对不同元素及其功能的解释都非常重要。因此，UML 有注释符号来支持这一要求。
注释符号
该表示法如下图所示。这些符号用于提供系统的必要信息。
人际关系
除非正确描述了元素之间的关系，否则模型是不完整的。关系为 UML模型赋予了正确的含义。以下是 UML 中可用的不同类型的关系。
- 依赖性
- 协会
- 概括
- 可扩展性
依赖符号
依赖性是 UML 元素的一个重要方面。它描述了依赖元素和依赖方向。
依赖关系由虚线箭头表示，如下图所示。箭头头代表独立元素，另一端代表从属元素。
依赖关系用于表示系统的两个元素之间的依赖关系
关联符号
关联描述了 UML 图中的元素如何关联。简而言之，它描述了有多少元素参与交互。
关联由两侧带（不带）箭头的虚线表示。两端代表两个关联的元素，如下图所示。末尾还提到了多重性（1、* 等），以显示有多少个对象关联。
关联用于表示系统的两个元素之间的关系。
泛化符号
泛化描述了面向对象世界的继承关系。这是一种父母和孩子的关系。
概括起来用带有空心箭头的箭头表示，如下图所示。一端代表父元素，另一端代表子元素。
泛化用于描述系统中两个元素的父子关系。
可扩展性符号
所有语言（编程或建模）都有一些机制来扩展其功能，例如语法、语义等。UML 还具有以下机制来提供可扩展性功能。
- 刻板印象（代表新元素）
- 标记值（代表新属性）
- 约束（代表边界）
可扩展性符号用于增强语言的功能。它基本上是用于表示系统的一些额外Behave的附加元素。标准可用符号未涵盖这些额外Behave。
UML - 标准图
在前面的章节中，我们讨论了 UML 的构建块和其他必要元素。现在我们需要了解在哪里使用这些元素。
这些元素就像组件一样，可以通过不同的方式关联起来形成完整的 UML 图片，即图表。因此，理解不同的图表以在现实系统中实现知识非常重要。
任何复杂的系统最好通过制作某种图表或图片来理解。这些图表对我们的理解有更好的影响。如果我们环顾四周，我们会发现图表并不是一个新概念，但它在不同行业以不同形式广泛使用。
我们准备 UML 图来更好、更简单地理解系统。单个图表不足以涵盖系统的所有方面。UML 定义了各种类型的图来涵盖系统的大部分方面。
您还可以创建自己的一组图表来满足您的要求。图表通常以增量和迭代的方式制作。
图表有两大类，它们又分为子类 -
结构图
Behave图
结构图
结构图表示系统的静态方面。这些静态方面代表了图表的那些部分，它们形成了主要结构，因此是稳定的。
这些静态部分由类、接口、对象、组件和节点表示。四个结构图是 -
- 类图
- 对象图
- 元件图
- 部署图
类图
类图是 UML 中最常用的图。类图由类、接口、关联和协作组成。类图基本上表示系统的面向对象视图，本质上是静态的。
活动类在类图中使用来表示系统的并发性。
类图表示系统的面向对象。因此，它通常用于开发目的。这是系统构建时使用最广泛的图。
对象图
对象图可以描述为类图的实例。因此，这些图更接近我们实现系统的现实场景。
对象图是一组对象，它们的关系就像类图一样。它们还代表系统的静态视图。
对象图的用法与类图类似，但它们用于从实际角度构建系统原型。
元件图
组件图表示一组组件及其关系。这些组件由类、接口或协作组成。组件图表示系统的实现视图。
在设计阶段，系统的软件工件（类、接口等）根据它们的关系被安排在不同的组中。现在，这些组被称为组件。
最后，可以说组件图用于可视化实现。
部署图
部署图是一组节点及其关系。这些节点是部署组件的物理实体。
部署图用于可视化系统的部署视图。这通常由部署团队使用。
注意- 如果仔细观察上述描述和用法，那么很明显所有图表都彼此之间存在某种关系。组件图依赖于类、接口等，它们是类/对象图的一部分。同样，部署图依赖于用于制作组件图的组件。
Behave图
任何系统都可以有两个方面：静态和动态。因此，当两个方面都被完全覆盖时，模型就被认为是完整的。
Behave图基本上捕获了系统的动态方面。动态方面可以进一步描述为系统的变化/移动部分。
UML 有以下五种类型的Behave图 -
- 用例图
- 时序图
- 协作图
- 状态图
- 活动图
用例图
用例图是一组用例、参与者及其关系。它们代表系统的用例视图。
用例代表系统的特定功能。因此，用例图用于描述功能及其内部/外部控制器之间的关系。这些控制器称为参与者。
时序图
序列图是交互图。从名称中可以清楚地看出，该图处理一些序列，这些序列是从一个对象流向另一个对象的消息序列。
从实施和执行的角度来看，系统组件之间的交互非常重要。序列图用于可视化系统中执行特定功能的调用序列。
合作图
协作图是交互图的另一种形式。它代表系统的结构组织和发送/接收的消息。结构组织由对象和链接组成。
协作图的目的与序列图类似。然而，协作图的具体目的是可视化对象的组织及其交互。
状态图
任何实时系统都会对某种内部/外部事件做出反应。这些事件负责系统的状态更改。
状态图用于表示系统的事件驱动的状态变化。它基本上描述了类、接口等的状态变化。
状态图用于可视化系统通过内部/外部因素的反应。
活动图
活动图描述了系统中的控制流程。它由活动和链接组成。该流程可以是顺序的、并发的或分支的。
活动只不过是系统的功能。准备许多活动图来捕获系统中的整个流程。
活动图用于可视化系统中的控制流程。这是为了了解系统执行时如何工作。
注意- 系统的动态特性很难捕捉。UML 提供了从不同角度捕捉系统动态的功能。序列图和协作图是同构的，因此它们可以相互转换而不会丢失任何信息。对于状态图和活动图也是如此。
UML - 类图
类图是静态图。它代表应用程序的静态视图。类图不仅用于可视化、描述和记录系统的不同方面，而且还用于构建软件应用程序的可执行代码。
类图描述了类的属性和操作以及对系统施加的约束。类图广泛应用于面向对象系统的建模中，因为它们是唯一可以用面向对象语言直接映射的UML图。
类图显示了类、接口、关联、协作和约束的集合。它也称为结构图。
类图的目的
类图的目的是对应用程序的静态视图进行建模。类图是唯一可以直接与面向对象语言映射的图，因此在构造时得到广泛使用。
UML图如活动图、序列图只能给出应用程序的序列流，但是类图有点不同。它是编码社区中最流行的 UML 图。
类图的目的可以概括为 -
应用程序静态视图的分析和设计。
描述系统的职责。
组件和部署图的基础。
正向和逆向工程。
如何绘制类图？
类图是用于构建软件应用程序的最流行的 UML 图。学习类图的绘制过程非常重要。
绘制类图时需要考虑很多属性，但这里将从顶层视图考虑该图。
类图基本上是系统静态视图的图形表示，代表应用程序的不同方面。类图的集合代表了整个系统。
绘制类图时应记住以下几点 -
类图的名称应该对描述系统的方面有意义。
应提前确定每个元素及其关系。
每个类的职责（属性和方法）应该明确标识
对于每个类，应指定最小数量的属性，因为不必要的属性会使图表变得复杂。
每当需要描述图表的某些方面时，请使用注释。绘图结束时，开发人员/编码人员应该可以理解。
最后，在制作最终版本之前，应将图表绘制在普通纸上，并尽可能多次修改以使其正确。
下图是应用程序的订单系统的示例。它描述了整个应用程序的一个特定方面。
首先，将订单和客户确定为系统的两个要素。它们具有一对多的关系，因为一个客户可以有多个订单。
Order类是一个抽象类，它有两个具体类（继承关系）SpecialOrder和NormalOrder。
这两个继承类具有 Order 类的所有属性。此外，它们还有额外的函数，如dispatch()和receive()。
考虑到上述所有要点，绘制了以下类图。
在哪里使用类图？
类图是静态图，用于对系统的静态视图进行建模。静态视图描述了系统的词汇表。
类图也被认为是组件图和部署图的基础。类图不仅用于可视化系统的静态视图，而且还用于构建任何系统的正向和逆向工程的可执行代码。
一般来说，UML 图不直接与任何面向对象的编程语言映射，但类图是一个例外。
类图清晰地展示了与Java、C++等面向对象语言的映射。从实践经验来看，类图一般用于构造目的。
简而言之，类图用于 -
描述系统的静态视图。
显示静态视图元素之间的协作。
描述系统执行的功能。
使用面向对象语言构建软件应用程序。
UML - 对象图
对象图派生自类图，因此对象图依赖于类图。
对象图表示类图的实例。类图和对象图的基本概念相似。对象图还表示系统的静态视图，但该静态视图是系统在特定时刻的快照。
对象图用于将一组对象及其关系呈现为实例。
对象图的目的
应该清楚地理解图表的目的才能实际实施。对象图的用途与类图类似。
不同之处在于，类图表示由类及其关系组成的抽象模型。然而，对象图代表特定时刻的实例，本质上是具体的。
这意味着对象图更接近实际的系统Behave。目的是捕获系统在特定时刻的静态视图。
对象图的目的可以概括为 -
正向和逆向工程。
系统的对象关系
交互的静态视图。
从实践角度理解对象Behave及其关系
如何绘制对象图？
我们已经讨论过对象图是类图的实例。它意味着对象图由类图中使用的事物的实例组成。
因此，这两个图都是由相同的基本元素组成，但形式不同。在类图中，元素以抽象形式表示蓝图，在对象图中，元素以具体形式表示现实世界的对象。
为了捕获特定的系统，类图的数量是有限的。然而，如果我们考虑对象图，那么我们可以拥有无限数量的实例，这些实例本质上是唯一的。仅考虑那些对系统有影响的实例。
从上面的讨论可以清楚地看出，单个对象图无法捕获所有必要的实例，或者更确切地说，无法指定系统的所有对象。因此，解决方案是 -
首先，分析系统并确定哪些实例具有重要数据和关联。
其次，仅考虑那些将涵盖功能的实例。
第三，实例数量不限，进行一些优化。
在绘制对象图之前，应记住并清楚理解以下内容 -
对象图由对象组成。
对象图中的链接用于连接对象。
对象和链接是用于构造对象图的两个元素。
之后，在开始构建图表之前需要决定以下事项 -
对象图应该有一个有意义的名称来表明其目的。
最重要的要素需要被确定。
对象之间的关联应明确。
需要捕获不同元素的值以包含在对象图中。
在需要更清晰的地方添加适当的注释。
下图是对象图的示例。它代表我们在类图一章中讨论的订单管理系统。下图是特定购买时间的系统实例。它有以下对象。
顾客
命令
特殊订单
正常顺序
现在，客户对象 (C) 与三个订单对象（O1、O2 和 O3）关联。这些订单对象与特殊订单和普通订单对象（S1、S2 和 N1）相关联。客户在考虑的特定时间有以下三个不同编号（12、32 和 40）的订单。
客户将来可以增加订单数量，在这种情况下，对象图将反映这一点。如果观察顺序、特殊顺序和正常顺序对象，那么您会发现它们具有一些值。
对于订单，值为 12、32 和 40，这意味着对象在捕获实例时的特定时刻（此处将购买的特定时间视为时刻）具有这些值
对于订单数为 20、30 和 60 的特殊订单和普通订单对象也是如此。如果考虑不同的购买时间，则这些值将相应变化。
考虑到上述所有要点，绘制了以下对象图
在哪里使用对象图？
对象图可以想象为正在运行的系统在特定时刻的快照。让我们考虑一个正在运行的火车的例子
现在，如果你给正在运行的火车拍一张照片，你会发现它的静态图片如下：
正在运行的特定状态。
特定数量的乘客。如果快照是在不同时间拍摄的，这将会改变
在这里，我们可以想象正在运行的火车的快照是一个具有上述值的对象。对于任何现实生活中的简单或复杂系统都是如此。
简而言之，可以说对象图用于 -
制作系统原型。
逆向工程。
对复杂数据结构进行建模。
从实践的角度理解系统。
UML - 组件图
组件图在性质和Behave方面有所不同。组件图用于对系统的物理方面进行建模。现在的问题是，这些物理方面是什么？物理方面是驻留在节点中的元素，例如可执行文件、库、文件、文档等。
组件图用于可视化系统中组件之间的组织和关系。这些图也用于制作可执行系统。
组件图的目的
组件图是 UML 中一种特殊的图。其目的也不同于迄今为止讨论的所有其他图表。它不描述系统的功能，但描述用于实现这些功能的组件。
因此，从这个角度来看，组件图用于可视化系统中的物理组件。这些组件是库、包、文件等。
组件图也可以描述为系统的静态实现视图。静态实现代表特定时刻组件的组织。
单个组件图不能代表整个系统，而是使用一组图来代表整体。
组件图的目的可以概括为 -
可视化系统的组件。
使用正向和逆向工程构建可执行文件。
描述组件的组织和关系。
如何绘制组件图？
组件图用于描述系统的物理工件。该工件包括文件、可执行文件、库等
该图的目的不同。组件图在应用程序的实现阶段使用。然而，它提前做好了准备，以可视化实施细节。
最初，系统是使用不同的 UML 图设计的，然后当工件准备就绪时，使用组件图来了解实现。
该图非常重要，因为没有它，应用程序就无法有效实施。准备充分的组件图对于应用程序性能、维护等其他方面也很重要。
在绘制组件图之前，应清楚地识别以下工件 -
系统中使用的文件。
与应用程序相关的库和其他工件。
工件之间的关系。
识别工件后，需要牢记以下几点。
使用有意义的名称来标识要为其绘制图表的组件。
在制作使用工具之前准备好心理布局。
使用注释来澄清要点。
以下是订单管理系统的组件图。在这里，工件是文件。该图显示了应用程序中的文件及其关系。实际上，组件图还包含dll、库、文件夹等。
在下图中，标识了四个文件并生成了它们的关系。组件图不能与所讨论的其他 UML 图直接匹配，因为它是为了完全不同的目的而绘制的。
考虑到上述所有要点，绘制了以下组件图。
在哪里使用组件图？
我们已经描述过组件图用于可视化系统的静态实现视图。组件图是用于不同目的的特殊类型的 UML 图。
这些图显示了系统的物理组件。为了澄清这一点，我们可以说组件图描述了系统中组件的组织。
组织可以进一步描述为系统中组件的位置。这些组件以特殊方式组织以满足系统要求。
正如我们已经讨论过的，这些组件是库、文件、可执行文件等。在实现应用程序之前，需要组织这些组件。该组件组织也是作为项目执行的一部分单独设计的。
从实现的角度来看，组件图非常重要。因此，应用程序的实施团队应该对组件细节有适当的了解
组件图可用于 -
对系统的组件进行建模。
对数据库模式建模。
对应用程序的可执行文件进行建模。
对系统的源代码进行建模。
UML - 部署图
部署图用于可视化部署软件组件的系统物理组件的拓扑。
部署图用于描述系统的静态部署视图。部署图由节点及其关系组成。
部署图的目的
术语“部署”本身描述了该图的用途。部署图用于描述部署软件组件的硬件组件。组件图和部署图密切相关。
组件图用于描述组件，部署图显示它们如何在硬件中部署。
UML 的主要设计目的是关注系统的软件工件。然而，这两个图是用于关注软件和硬件组件的特殊图。
大多数 UML 图用于处理逻辑组件，但部署图则侧重于系统的硬件拓扑。部署图供系统工程师使用。
部署图的目的可以描述为 -
可视化系统的硬件拓扑。
描述用于部署软件组件的硬件组件。
描述运行时处理节点。
如何绘制部署图？
部署图表示系统的部署视图。它与组件图相关，因为组件是使用部署图来部署的。部署图由节点组成。节点只不过是用于部署应用程序的物理硬件。
部署图对于系统工程师很有用。有效的部署图非常重要，因为它控制以下参数 -
表现
可扩展性
可维护性
可移植性
在绘制部署图之前，应确定以下工件 -
节点
节点之间的关系
以下是一个示例部署图，以提供订单管理系统的部署视图的想法。在这里，我们将节点显示为 -
监视器
调制解调器
缓存服务器
服务器
假设该应用程序是基于 Web 的应用程序，它部署在使用服务器 1、服务器 2 和服务器 3 的集群环境中。用户使用 Internet 连接到该应用程序。控制流从缓存服务器流向集群环境。
考虑到上述所有要点，绘制了以下部署图。
在哪里使用部署图？
部署图主要由系统工程师使用。这些图用于描述物理组件（硬件）、它们的分布和关联。
部署图可以可视化为软件组件所在的硬件组件/节点。
软件应用程序被开发来模拟复杂的业务流程。高效的软件应用程序不足以满足业务需求。业务需求可以描述为需要支持不断增加的用户数量、快速响应时间等。
为了满足这些类型的要求，应该以经济有效的方式有效地设计硬件组件。
当今的软件应用程序本质上非常复杂。软件应用程序可以是独立的、基于网络的、分布式的、基于大型机的等等。因此，有效地设计硬件组件非常重要。
可以使用部署图 -
对系统的硬件拓扑进行建模。
对嵌入式系统进行建模。
对客户端/服务器系统的硬件详细信息进行建模。
对分布式应用程序的硬件细节进行建模。
用于正向和逆向工程。
UML - 用例图
为了对系统进行建模，最重要的方面是捕获动态Behave。动态Behave是指系统运行/操作时的Behave。
仅静态Behave不足以对系统进行建模，动态Behave比静态Behave更重要。在 UML 中，有五种图可用于对动态性质进行建模，用例图就是其中之一。现在我们必须讨论用例图本质上是动态的，因此应该有一些内部或外部因素来进行交互。
这些内部和外部代理称为参与者。用例图由参与者、用例及其关系组成。该图用于对应用程序的系统/子系统进行建模。单个用例图捕获系统的特定功能。
因此，为了对整个系统进行建模，需要使用许多用例图。
用例图的目的
用例图的目的是捕获系统的动态方面。然而，这个定义太笼统，无法描述其目的，因为其他四个图（活动、序列、协作和状态图）也具有相同的目的。我们将研究一些特定的目的，这将把它与其他四个图区分开来。
用例图用于收集系统的需求，包括内部和外部影响。这些要求大多是设计要求。因此，当分析系统以收集其功能时，就可以准备用例并识别参与者。
初始任务完成后，将对用例图进行建模以呈现外部视图。
简而言之，用例图的目的可以说如下：
用于收集系统的需求。
用于获取系统的外部视图。
识别影响系统的外部和内部因素。
显示需求之间的交互是参与者。
如何绘制用例图？
用例图用于系统的高级需求分析。当分析系统的需求时，在用例中捕获功能。
我们可以说用例只不过是以有组织的方式编写的系统功能。与用例相关的第二件事是参与者。参与者可以定义为与系统交互的东西。
参与者可以是人类用户、某些内部应用程序，也可以是某些外部应用程序。当我们计划绘制用例图时，我们应该确定以下项目。
表示为用例的功能
演员
用例和参与者之间的关系。
绘制用例图是为了捕获系统的功能需求。确定了上述各项后，我们必须使用以下准则来绘制有效的用例图
用例的名称非常重要。名称的选择应使其能够识别所执行的功能。
给演员起一个合适的名字。
在图中清楚地显示关系和依赖关系。
不要试图包含所有类型的关系，因为该图的主要目的是识别需求。
每当需要澄清一些要点时，请使用注释。
以下是代表订单管理系统的示例用例图。因此，如果我们查看该图，我们会发现三个用例（订单、特殊订单和正常订单）和一个参与者（即客户）。
SpecialOrder 和 NormalOrder 用例是从Order用例扩展而来的。因此，他们的关系很延伸。另一个重要的点是识别系统边界，如图所示。参与者 Customer 位于系统外部，因为它是系统的外部用户。
在哪里使用用例图？
正如我们已经讨论过的，UML 中有五个图来对系统的动态视图进行建模。现在每个模型都有一些特定的用途。实际上这些特定的目的是一个运行系统的不同角度。
为了理解系统的动态，我们需要使用不同类型的图表。用例图就是其中之一，其特定目的是收集系统需求和参与者。
用例图指定系统的事件及其流程。但用例图从未描述它们是如何实现的。用例图可以想象为一个黑匣子，其中只有输入、输出和黑匣子的功能是已知的。
这些图表用于非常高水平的设计。这种高层设计经过一次又一次的完善，以获得系统的完整和实用的画面。结构良好的用例还描述前置条件、后置条件和异常。这些额外的元素用于在执行测试时制作测试用例。
尽管用例不是正向和逆向工程的良好候选者，但它们在进行正向和逆向工程时的使用方式仍然略有不同。逆向工程也是如此。用例图的使用方式不同，使其适合逆向工程。
在正向工程中，用例图用于制作测试用例，而在逆向工程中，用例图用于根据现有应用程序准备需求详细信息。
用例图可用于 -
需求分析和高层设计。
对系统的上下文进行建模。
逆向工程。
正向工程。
UML - 交互图
从术语“交互”来看，很明显该图用于描述模型中不同元素之间的某种类型的交互。这种相互作用是系统动态Behave的一部分。
这种交互Behave在 UML 中通过称为序列图和协作图的两个图来表示。这两个图的基本目的是相似的。
顺序图强调消息的时间顺序，协作图强调发送和接收消息的对象的结构组织。
交互图的目的
交互图的目的是可视化系统的交互Behave。可视化交互是一项艰巨的任务。因此，解决方案是使用不同类型的模型来捕获交互的不同方面。
序列图和协作图用于从不同的角度捕捉动态本质。
交互图的目的是 -
捕获系统的动态Behave。
描述系统中的消息流。
描述对象的结构组织。
描述对象之间的相互作用。
如何绘制交互图？
正如我们已经讨论过的，交互图的目的是捕捉系统的动态方面。因此，为了捕捉动态方面，我们需要了解什么是动态方面以及它是如何可视化的。动态方面可以定义为运行系统在特定时刻的快照
UML 中有两种类型的交互图。一种是顺序图，另一种是协作图。序列图捕获从一个对象到另一个对象的消息流的时间顺序，协作图描述系统中参与消息流的对象的组织。
在绘制交互图之前需要明确以下几点
参与交互的对象。
消息在对象之间流动。
消息流动的顺序。
对象组织。
以下是对订单管理系统进行建模的两个交互图。第一个图是顺序图，第二个图是协作图
序列图
序列图有四个对象（Customer、Order、SpecialOrder 和 NormalOrder）。
下图显示了SpecialOrder对象的消息序列，并且可以在NormalOrder对象的情况下使用相同的消息序列。了解消息流的时间顺序非常重要。消息流只不过是对象的方法调用。
第一个调用是sendOrder() ，它是Order 对象的方法。下一个调用是confirm() ，它是SpecialOrder对象的方法，最后一个调用是Dispatch() ，它是SpecialOrder对象的方法。下图主要描述了一个对象到另一个对象的方法调用，这也是系统运行时的实际场景。
协作图
第二个交互图是协作图。它显示了对象组织，如下图所示。在协作图中，方法调用顺序由某种编号技术指示。数字表示方法是如何依次调用的。我们采用相同的订单管理系统来描述协作图。
方法调用类似于序列图。然而，不同之处在于序列图不描述对象组织，而协作图显示对象组织。
要在这两个图之间进行选择，重点在于需求的类型。如果时间顺序很重要，则使用顺序图。如果需要组织，则使用协作图。
