UML - 快速指南 UML - 活动图 UML 2.0 - 概述 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概念变得很重要。 以下是面向对象世界的一些基本概念 对象 - 对象表示实体和基本构建块。 Class - Class是对象的蓝图。 抽象 - 抽象代表现实世界实体的行为。 封装 - 封装是将数据绑定在一起并将其隐藏在外部世界的机制。 继承 - 继承是从现有类创建新类的机制。 多态性 - 它定义了以不同形式存在的机制。 OO分析与设计 OO可以定义为调查，更具体地说，它是对象的调查。设计意味着已识别对象的协作。 因此，理解OO分析和设计概念非常重要。OO分析的最重要目的是识别要设计的系统的对象。该分析也针对现有系统进行。现在，只有当我们能够以可以识别对象的方式开始思考时，才有可能进行有效的分析。在识别对象之后，识别它们的关系并最终产生设计。 OO分析和设计的目的可以描述为 识别系统的对象。 确定他们的关系。 进行设计，可以使用OO语言转换为可执行文件。 应用和实施OO概念有三个基本步骤。这些步骤可以定义为 OO Analysis → OO Design → OO implementation using OO languages 以上三点可详细描述如下 在面向对象分析期间，最重要的目的是识别对象并以适当的方式描述它们。如果能够有效识别这些对象，那么下一个设计工作就很容易了。应该用责任来确定对象。责任是对象执行的功能。每个对象都有某种类型的责任要执行。当这些责任合作时，系统的目的就实现了。 第二阶段是OO设计。在此阶段，重点放在要求及其实现上。在这个阶段，对象根据其预期的关联进行协作。关联完成后，设计也完成了。 第三阶段是OO实施。在这个阶段，设计是使用Java，C ++等OO语言实现的。 UML在面向对象设计中的作用 UML是一种用于建模软件和非软件系统的建模语言。虽然UML用于非软件系统，但重点是对OO软件应用程序进行建模。到目前为止讨论的大多数UML图用于模拟不同的方面，例如静态，动态等。现在无论是什么方面，工件都只是对象。 如果我们查看类图，对象图，协作图，交互图都基本上都是基于对象设计的。 因此，OO设计和UML之间的关系非常重要。根据需要将OO设计转换为UML图。在详细了解UML之前，应该正确地学习OO概念。一旦OO分析和设计完成，下一步就很容易了。OO分析和设计的输入是UML图的输入。 UML - 构建块 当UML描述实时系统时，制作概念模型然后逐步进行是非常重要的。通过学习以下三个主要元素，可以掌握UML的概念模型 - UML构建块 连接构建块的规则 UML的常见机制 本章介绍了所有UML构建块。UML的构建块可以定义为 - 事情 关系 图 事情 事物 是UML最重要的构建块。事情可以是 结构 行为的 分组 注释性 结构性事物 结构性事物 定义了模型的静态部分。它们代表了物理和概念元素。以下是结构性事物的简要描述。 Class - Class表示具有相似职责的一组对象。 Interface - Interface定义了一组操作，用于指定类的职责。 协作 - 协作定义元素之间的交互。 用例 - 用例表示系统针对特定目标执行的一组操作。 组件 - 组件描述系统的物理部分。 节点 - 节点可以定义为在运行时存在的物理元素。 行为事物 行为事物 由UML模型的动态部分组成。以下是行为事物 - 交互 - 交互定义为由元素之间交换的一组消息组成的行为，以完成特定任务。 状态机 - 状态机在其生命周期中的对象状态很重要时很有用。它定义了对象响应事件所经历的状态序列。事件是导致状态变化的外部因素 分组事物 **可以将 分组事物** 定义为将UML模型的元素组合在一起的机制。只有一个分组可用 - 包 - 包是唯一可用于收集结构和行为事物的分组事物。 注释事物 注释事物 可以定义为捕获UML模型元素的注释，描述和注释的机制。 注意 - 这是唯一一个可用的注释事物。 注释用于呈现UML元素的注释，约束等。 关系 关系 是UML的另一个最重要的构建块。它显示了元素如何相互关联，并且此关联描述了应用程序的功能。 有四种关系可供选择。 依赖 依赖性是两个事物之间的关系，其中一个元素的变化也影响另一个元素。 协会 关联基本上是一组连接UML模型元素的链接。它还描述了有多少对象参与了这种关系。 概括 泛化可以定义为将专用元素与通用元素连接起来的关系。它基本上描述了对象世界中的继承关系。 实现 实现可以定义为连接两个元素的关系。一个元素描述了一些责任，这个责任没有实现，另一个元素实现了它们。在接口的情况下存在这种关系。 UML图 UML图是整个讨论的最终输出。所有元素，关系用于制作完整的UML图，图表代表系统。 UML图的视觉效果是整个过程中最重要的部分。所有其他元素都用于完成它。 UML包括以下九个图，其细节将在后续章节中描述。 类图 对象图 用例图 序列图 协作图 活动图 状态图 部署图 组件图 UML - 架构 任何真实世界的系统都由不同的用户使用。用户可以是开发人员，测试人员，业务人员，分析人员等等。因此，在设计系统之前，架构的设计考虑了不同的观点。最重要的部分是从不同观众的角度可视化系统。我们越了解我们就能越好地构建系统。 UML在定义系统的不同视角方面发挥着重要作用。这些观点是 - 设计 履行 处理 部署 该中心是 用例 视图，它连接所有这四个。一个 用例 表示系统的功能。因此，其他观点与用例相关。 **系统的 设计** 包括类，接口和协作。UML提供类图，对象图来支持这一点。 实现 定义了组装在一起的组件，以构建完整的物理系统。UML组件图用于支持实现透视图。 流程 定义了系统的流程。因此，与Design中使用的元素相同的元素也用于支持这种观点。 部署 代表构成硬件的系统的物理节点。UML部署图用于支持此透视图。 UML - 建模类型 区分UML模型非常重要。不同的图表用于不同类型的UML建模。有三种重要的UML建模类型。 结构建模 结构建模捕获系统的静态特征。它们包括以下内容 - 类图 对象图 部署图 包图 复合结构图 组件图 结构模型表示系统的框架，该框架是存在所有其他组件的地方。因此，类图，组件图和部署图是结构建模的一部分。它们都代表了组装它们的要素和机制。 结构模型从未描述系统的动态行为。类图是最广泛使用的结构图。 行为建模 行为模型描述了系统中的交互。它代表了结构图之间的相互作用。行为建模显示了系统的动态特性。它们包括以下内容 - 活动图 交互图 用例图 以上所有都显示了系统中的动态流程序列。 建筑模型 架构模型代表了系统的整体框架。它包含系统的结构和行为元素。建筑模型可以定义为整个系统的蓝图。包图来自架构建模。 UML - 基本表示法 UML因其图解符号而广受欢迎。我们都知道UML用于可视化，指定，构建和记录软件和非软件系统的组件。因此，可视化是需要理解和记住的最重要的部分。 UML符号是建模中最重要的元素。有效和恰当地使用符号对于制作完整且有意义的模型非常重要。除非正确描述其目的，否则该模型是无用的。 因此，应该从一开始就强调学习符号。事物和关系可以使用不同的符号。UML图是使用事物和关系的符号制作的。可扩展性是使UML更强大和灵活的另一个重要特性。 本章详细介绍了基本的UML符号。这只是第二章中讨论的UML构建块部分的扩展。 结构性事物 结构化事物中使用的图形符号在UML中使用最为广泛。这些被认为是UML模型的名词。以下是结构性事物清单。 类 目的 接口 合作 用例 活跃的课程 组件 节点 类符号 UML 类 由下图表示。该图分为四个部分。 顶部用于命名类。 第二个用于显示类的属性。 第三部分用于描述该类执行的操作。 第四部分是可选的，以显示任何其他组件。 类用于表示对象。对象可以是具有属性和责任的任何东西。 对象表示法 该 对象 以与该类相同的方式表示。唯一的区别是下划线的 名称 ，如下图所示。 由于对象是类的实际实现，因此称为类的实例。因此，它与类具有相同的用法。 接口表示法 界面用圆圈表示，如下图所示。它的名称通常写在圆圈下面。 接口用于描述功能而无需实现。接口就像一个模板，您可以在其中定义不同的功能，而不是实现。当类实现接口时，它还根据需要实现功能。 协作表示法 协作由虚线日食表示，如下图所示。它的名字写在日食中。 协作代表着责任。一般来说，责任属于一个群体。 用例表示法 用例表示为带有名称的eclipse。它可能包含额外的责任。 用例用于捕获系统的高级功能。 演员记谱法 可以将actor定义为与系统交互的某个内部或外部实体。 在用例图中使用actor来描述内部或外部实体。 初始状态表示法 初始状态定义为显示进程的开始。几乎所有图表都使用此表示法。 初始状态表示法的用法是显示进程的起点。 最终状态表示法 最终状态用于显示流程的结束。这种表示法也用于几乎所有的图表来描述结束。 最终状态表示法的用法是显示进程的终止点。 活动类表示法 活动类看起来类似于具有实线边框的类。活动类通常用于描述系统的并发行为。 活动类用于表示系统中的并发性。 组件表示法 UML中的组件如下图所示，其中包含名称。可以在需要的地方添加其他元素。 组件用于表示为其制作UML图的系统的任何部分。 节点表示法 UML中的节点由方框表示，如下图所示，带有名称。节点表示系统的物理组件。 节点用于表示系统的物理部分，例如服务器，网络等。 行为事物 动态部分是UML中最重要的元素之一。UML具有一组强大的功能来表示软件和非软件系统的动态部分。这些功能包括 交互 和 状态机 。 交互可以有两种类型 - 顺序（由序列图表示） 协作（由协作图表示） 交互表示法 交互基本上是两个UML组件之间的消息交换。下图表示交互中使用的不同符号。 交互用于表示系统组件之间的通信。 状态机表示法 状态机描述组件生命周期中的不同状态。符号如下图所示。 状态机用于描述系统组件的不同状态。根据情况，状态可以是活动的，空闲的或任何其他状态。 分组事物 组织UML模型是设计中最重要的方面之一。在UML中，只有一个元素可用于分组，即包。 包装表示法 包符号如下图所示，用于包装系统的组件。 注释事物 在任何图表中，对不同元素及其功能的解释都非常重要。因此，UML具有支持此要求的 注释 符号。 注意符号 该符号如下图所示。这些符号用于提供系统的必要信息。 关系 除非正确描述元素之间的关系，否则模型不完整。该 关系 给出了一个应有之义为UML模型。以下是UML中可用的不同类型的关系。 依赖 协会 概括 可扩展性 依赖符号 依赖性是UML元素中的一个重要方面。它描述了依赖元素和依赖的方向。 依赖关系由虚线箭头表示，如下图所示。箭头表示独立元素，另一端表示从属元素。 依赖关系用于表示系统的两个元素之间的依赖关系 关联表示法 Association描述了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 - 对象图 对象图是从类图中派生出来的，因此对象图依赖于类图。 对象图表示类图的实例。类图和对象图的基本概念类似。对象图还表示系统的静态视图，但此静态视图是特定时刻系统的快照。 对象图用于将一组对象及其关系呈现为实例。 对象图的目的 应清楚地理解图表的目的以实际实现它。对象图的目的与类图类似。 不同之处在于，类图表示由类及其关系组成的抽象模型。然而，对象图表示特定时刻的实例，其本质上是具体的。 这意味着对象图更接近实际的系统行为。目的是在特定时刻捕获系统的静态视图。 对象图的目的可以概括为 - 正向和反向工程。 系统的对象关系 静态视图的交互。 从实践角度理解对象行为及其关系 如何绘制对象图？ 我们已经讨论过，对象图是类图的一个实例。它意味着对象图由类图中使用的事物实例组成。 因此，两个图表都由相同的基本元素组成，但形式不同。在类图中，元素采用抽象形式表示蓝图，而在对象图中元素采用具体形式表示现实世界对象。 为了捕获特定系统，类图的数量是有限的。但是，如果我们考虑对象图，那么我们可以拥有无限数量的实例，这些实例本质上是唯一的。仅考虑那些对系统有影响的实例。 从上面的讨论中可以清楚地看出，单个对象图不能捕获所有必需的实例，或者不能指定系统的所有对象。因此，解决方案是 - 首先，分析系统并确定哪些实例具有重要数据和关联。 其次，只考虑那些将涵盖功能的实例。 第三，进行一些优化，因为实例的数量是无限的。 在绘制对象图之前，应记住并清楚地理解以下内容 - 对象图由对象组成。 对象图中的链接用于连接对象。 对象和链接是用于构造对象图的两个元素。 在此之后，在开始构建图之前要确定以下事项 - 对象图应该有一个有意义的名称来表示其用途。 最重要的要素是要确定的。 应澄清对象之间的关联。 需要捕获不同元素的值以包括在对象图中。 在需要更清晰的点处添加适当的注释。 下图是对象图的示例。它代表了我们在类图中章节中讨论过的订单管理系统。下图是特定购买时系统的实例。它具有以下对象。 顾客 订购 特殊订单 NormalOrder 现在，客户对象（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中，有五个可用于建模动态性质的图表，用例图表就是其中之一。现在我们必须讨论用例图本质上是动态的，应该有一些内部或外部因素来进行交互。 这些内部和外部代理被称为actor。用例图由演员，用例及其关系组成。该图用于建模应用程序的系统/子系统。单个用例图捕获系统的特定功能。 因此，为了对整个系统进行建模，使用了许多用例图。 用例图的目的 用例图的目的是捕获系统的动态方面。但是，这个定义过于通用，无法描述目的，因为其他四个图（活动，序列，协作和状态图）也具有相同的目的。我们将研究一些特定目的，这将与其他四个图区别开来。 用例图用于收集系统的要求，包括内部和外部影响。这些要求主要是设计要求。因此，当分析系统以收集其功能时，准备用例并识别参与者。 初始任务完成后，将使用用例图建模以显示外部视图。 简而言之，用例图的目的可以说如下 - 用于收集系统的要求。 用于获取系统的外部视图。 确定影响系统的外部和内部因素。 展示要求之间的互动是演员。 如何绘制用例图？ 用例图被考虑用于系统的高级需求分析。当分析系统的要求时，在用例中捕获功能。 我们可以说用例只不过是以有组织的方式编写的系统功能。与用例相关的第二件事是演员。可以将Actor定义为与系统交互的东西。 Actor可以是人类用户，某些内部应用程序，也可以是某些外部应用程序。当我们计划绘制用例图时，我们应该确定以下项目。 功能性表示为用例 演员 用例和参与者之间的关系。 绘制用例图以捕获系统的功能要求。在确定上述项目后，我们必须使用以下指南来绘制有效的用例图 用例的名称非常重要。应该以这样的方式选择名称，以便它可以识别所执行的功能。 为演员提供合适的名字。 在图中清楚地显示关系和依赖关系。 不要试图包含所有类型的关系，因为图的主要目的是确定需求。 必要时使用注释来澄清一些重点。 以下是表示订单管理系统的示例用例图。因此，如果我们查看图表，那么我们将找到三个用例 （Order，SpecialOrder和NormalOrder） 和一个作为客户的actor。 SpecialOrder和NormalOrder用例从 Order 用例扩展而来。因此，他们扩大了关系。另一个重点是识别系统边界，如图所示。演员Customer位于系统外部，因为它是系统的外部用户。 在哪里使用用例图？ 正如我们已经讨论过的，UML中有五个图来模拟系统的动态视图。现在每个模型都有一些特定的用途。实际上，这些特定目的是运行系统的不同角度。 要了解系统的动态，我们需要使用不同类型的图表。用例图是其中之一，其具体目的是收集系统需求和参与者。 用例图指定系统的事件及其流程。但是用例图从未描述过它们是如何实现的。用例图可以想象为黑盒子，其中只有黑盒子的输入，输出和功能是已知的。 这些图表用于非常高的设计水平。这种高级设计一次又一次地得到完善，以获得完整而实用的系统图像。结构良好的用例还描述了前置条件，后置条件和异常。这些额外元素用于在执行测试时生成测试用例。 虽然用例不是正向和反向工程的良好候选者，但它们仍然以稍微不同的方式用于进行正向和反向工程。逆向工程也是如此。用例图的使用方式不同，使其适用于逆向工程。 在正向工程中，用例图用于制作测试用例，在逆向工程中，用例用于从现有应用程序中准备要求详细信息。 用例图可用于 需求分析和高级设计。 模拟系统的上下文。 逆向工程。 正向工程。 UML - 交互图 从术语“交互”中可以清楚地看出，该图用于描述模型中不同元素之间的某种类型的交互。这种交互是系统动态行为的一部分。 此交互行为在UML中由两个图表表示，称为 序列图 和 协作图 。两个图的基本目的是相似的。 序列图强调消息的时间顺序，协作图强调发送和接收消息的对象的结构组织。 交互图的目的 交互图的目的是可视化系统的交互行为。可视化交互是一项艰巨的任务。因此，解决方案是使用不同类型的模型来捕获交互的不同方面。 序列和协作图用于捕捉动态性质，但是从不同的角度。 交互图的目的是 捕获系统的动态行为。 描述系统中的消息流。 描述对象的结构组织。 描述对象之间的交互。 如何绘制交互图？ 正如我们已经讨论过的，交互图的目的是捕获系统的动态方面。因此，为了捕捉动态方面，我们需要了解动态方面是什么以及它是如何可视化的。动态方面可以定义为特定时刻运行系统的快照 我们在UML中有两种类型的交互图。一个是序列图，另一个是协作图。序列图捕获从一个对象到另一个对象的消息流的时间顺序，协作图描述了参与消息流的系统中对象的组织。 在绘制交互图之前，要清楚地识别以下内容 参与互动的对象。 消息在对象之间流动。 消息流动的顺序。 对象组织。 以下是对订单管理系统进行建模的两个交互图。第一个图是序列图，第二个图是协作图 序列图 序列图有四个对象（Customer，Order，SpecialOrder和NormalOrder）。 下图显示了 SpecialOrder 对象的消息序列，并且在 NormalOrder 对象的情况下也可以使用相同的消息序列。了解消息流的时间顺序非常重要。消息流只不过是对象的方法调用。 第一个调用是 sendOrder（） ，它是 Order对象的 一个方法。下一个调用是 confirm（） ，它是 SpecialOrder 对象的方法，最后一个调用是 Dispatch（） ，它是 SpecialOrder 对象的方法。下图主要描述了从一个对象到另一个对象的方法调用，这也是系统运行时的实际场景。 协作图 第二个交互图是协作图。它显示了对象组织，如下图所示。在协作图中，方法调用序列由一些编号技术指示。该数字表示如何一个接一个地调用这些方法。我们采用相同的订单管理系统来描述协作图。 方法调用类似于序列图。但是，序列图的差异不描述对象组织，而协作图则显示对象组织。 要在这两个图表之间进行选择，重点放在需求类型上。如果时间顺序很重要，则使用序列图。如果需要组织，则使用协作图。 在哪里使用交互图？ 我们已经讨论过，交互图用于描述系统的动态特性。现在，我们将研究使用这些图表的实际场景。要了解实际应用，我们需要了解序列和协作图的基本性质。 两个图的主要目的是相似的，因为它们用于捕获系统的动态行为。但是，具体目的更为澄清和理解。 序列图用于捕获从一个对象流向另一个对象的消息的顺序。协作图用于描述参与交互的对象的结构组织。单个图表不足以描述整个系统的动态方面，因此使用一组图表作为整体捕获它。 当我们想要了解消息流和结构组织时，使用交互图。消息流意味着从一个对象到另一个对象的控制流序列。结构组织是指系统中元素的可视化组织。 可以使用交互图 - 按时间顺序模拟控制流程。 模拟结构组织的控制流程。 对于正向工程。 用于逆向工程。 UML - Statechart Diagrams 图表的名称本身阐明了图表的目的和其他细节。它描述了系统中组件的不同状态。状态特定于系统的组件/对象。 状态图描述了状态机。状态机可以定义为定义对象的不同状态的机器，这些状态由外部或内部事件控制。 活动图在下一章中解释，是一种特殊的状态图。当状态图定义状态时，它用于模拟对象的生命周期。 状态图的目的 状态图是用于模拟系统动态特性的五个UML图之一。它们定义了对象在其生命周期中的不同状态，并且这些状态由事件更改。状态图对于反应系统的建模很有用。可以将反应系统定义为响应外部或内部事件的系统。 状态图描述了从一个状态到另一个状态的控制流。状态被定义为对象存在的条件，并且在触发某个事件时它会发生变化。状态图最重要的目的是模拟对象从创建到终止的生命周期。 状态图也用于系统的正向和反向工程。但是，主要目的是模拟反应系统。 以下是使用状态图的主要目的 - 模拟系统的动态方面。 模拟反应系统的寿命。 描述对象在其生命周期中的不同状态。 定义状态机以模拟对象的状态。 如何绘制状态图？ 状态图用于描述生命周期中不同对象的状态。重点放在一些内部或外部事件的状态变化上。这些对象状态对于准确分析和实现它们非常重要。 状态图对于描述状态非常重要。当特定事件发生时，可以将状态识别为对象的条件。 在绘制状态图之前，我们应该澄清以下几点 - 确定要分析的重要对象。 确定状态。 确定事件。 以下是状态图的示例，其中分析了Order对象的状态 第一个状态是进程开始的空闲状态。接下来的状态是发送请求，确认请求和发送订单等事件。这些事件负责订单对象的状态更改。 在对象的生命周期（此处为订单对象）期间，它会经历以下状态，并且可能存在一些异常退出。由于系统中的某些问题，可能会发生此异常退出。当整个生命周期完成时，它被视为完整的事务，如下图所示。对象的初始状态和最终状态也显示在下图中。 在哪里使用状态图？ 从上面的讨论中，我们可以定义状态图的实际应用。状态图用于模拟系统的动态方面，就像本教程中讨论的其他四个图一样。然而，它具有一些区别于动态性建模的特征。 状态图定义了组件的状态，这些状态变化本质上是动态的。其具体目的是定义事件触发的状态更改。事件是影响系统的内部或外部因素。 状态图用于模拟状态以及在系统上运行的事件。在实现系统时，明确对象在其生命周期中的不同状态非常重要，并且状态图用于此目的。当识别出这些状态和事件时，它们用于对其进行建模，并且在系统的实现期间使用这些模型。 如果我们研究状态图的实际实现，那么它主要用于分析受事件影响的对象状态。此分析有助于了解执行期间的系统行为。 主要用途可以描述为 - 模拟系统的对象状态。 模拟反应系统。反应系统由反应对象组成。 识别负责状态变化的事件。 正向和反向工程。 UML - 活动图 活动图是UML中用于描述系统动态方面的另一个重要图表。 活动图基本上是表示从一个活动到另一个活动的流程的流程图。活动可以描述为系统的操作。 控制流程从一个操作引出到另一个操作。该流可以是顺序的，分支的或并发的。活动图通过使用不同的元素（如fork，join等）来处理所有类型的流控制 活动图的目的 活动图的基本用途与其他四个图类似。它捕获系统的动态行为。其他四个图用于显示从一个对象到另一个对象的消息流，但活动图用于显示从一个活动到另一个活动的消息流。 活动是系统的特定操作。活动图不仅用于可视化系统的动态特性，而且还用于通过使用正向和逆向工程技术构建可执行系统。活动图中唯一缺少的是消息部分。 它不显示从一个活动到另一个活动的任何消息流。活动图有时被视为流程图。虽然图表看起来像流程图，但它们不是。它显示了不同的流，如并行，分支，并发和单一。 活动图的目的可以描述为 - 绘制系统的活动流程。 描述从一个活动到另一个活动的顺序。 描述系统的并行，分支和并发流程。 如何绘制活动图？ 活动图主要用作由系统执行的活动组成的流程图。活动图并不完全是流程图，因为它们具有一些额外的功能。这些附加功能包括分支，并行流，泳道等。 在绘制活动图之前，我们必须清楚地了解活动图中使用的元素。活动图的主要元素是活动本身。活动是由系统执行的功能。在确定活动之后，我们需要了解它们与约束和条件的关联。 在绘制活动图之前，我们应该确定以下要素 - 活动 协会 条件 约束 一旦识别出上述参数，我们就需要对整个流程进行心理布局。然后将此心理布局转换为活动图。 以下是订单管理系统的活动图示例。在该图中，识别出与条件相关的四个活动。应该清楚地理解一个重要的观点，即活动图不能与代码完全匹配。活动图用于理解活动流程，主要由业务用户使用 下图是四个主要活动 - 由客户发送订单 收到订单 确认订单 发货订单 收到订单请求后，执行条件检查以检查它是正常还是特殊订单。在识别出订单类型后，执行调度活动并将其标记为流程的终止。 在哪里使用活动图？ 活动图的基本用法与其他四个UML图类似。具体用法是将控制流从一个活动建模到另一个活动。此控制流程不包括消息。 活动图适用于对系统的活动流进行建模。应用程序可以有多个系统。活动图还捕获这些系统并描述从一个系统到另一个系统的流程。其他图表中没有此特定用法。这些系统可以是数据库，外部队列或任何其他系统。 我们现在将研究活动图的实际应用。从上面的讨论中可以清楚地看出，活动图是从非常高的层次得出的。因此它提供了系统的高级视图。此高级视图主要面向商业用户或任何其他非技术人员。 此图用于对活动进行建模，这些活动只是业务需求。该图对业务理解而不是实现细节有更大的影响。 活动图可用于 使用活动建模工作流程。 建模业务需求。 高度了解系统的功能。 在稍后阶段调查业务需求。 UML - 活动图 UML 2.0 - 概述
