本文共 9527 字，大约阅读时间需要 31 分钟。
本节书摘来自异步社区《UML用户指南（第2版.修订版）》一书中的第2章2.2节UML的概念模型，作者【美】Grady Booch , James Rumbaugh , Ivar Jacobson，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.2 UML的概念模型
UML用户指南（第2版.修订版）为了理解UML，需要形成该语言的概念模型，这要求学习建模的3个要素：UML的基本构造块、支配这些构造块如何放在一起的规则和一些运用于整个UML的公共机制。如果掌握了这些思想，就能够读懂UML模型，并能建立一些基本模型。当有了较丰富的应用UML的经验时，就能够在这些概念模型之上使用更高深的语言特征进行构造。2.2.1 UML的构造块
UML的词汇表包含下面3种构造块：（1）事物；
（2）关系；
（3）图。
事物是对模型中首要成分的抽象；关系把事物结合在一起；图聚集了相关的事物。
1．UML中的事物
在UML中有4种事物：
（1）结构事物；
（2）行为事物；
（3）分组事物；
（4）注释事物。
这些事物是UML中基本的面向对象的构造块，用它们可以写出形式良好的模型。
2．结构事物
结构事物（structural thing）是UML模型中的名词。它们通常是模型的静态部分，描述概念元素或物理元素。结构事物总称为类目（classifier）。
第一，类（class）是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述。类实现一个或多个接口。在图形上，把类画成一个矩形，矩形中通常包括类的名称、属性和操作，如图2-1所示。
【第4章和第9章讨论类。】
第二，接口（interface）是一组操作的集合，其中的每个操作描述了类或构件的一个服务。因此，接口描述了元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。接口定义了一组操作规约（即操作的特征标记），而不是操作的实现。接口的声明看上去像一个类，在名称的上方标注着关键字«interface»；除非有时用来表示常量，否则不需要属性。然而，接口很少单独出现。如图 2-2 所示，把由类提供的对外接口表示成用线连接到类框的一个小圆圈，把类向其他类请求的接口表示成用线连接到类框的半个小圆圈。
【第11章讨论接口。】
【第28章讨论协作。】
第四，用况（use case）是对一组动作序列的描述，系统执行这些动作将产生对特定的参与者有价值而且可观察的结果。用况用于构造模型中的行为事物。用况是通过协作实现的。在图形上，把用况画成实线椭圆，通常仅包含它的名称，如图2-4所示。
【第17章讨论用况。】
第五，主动类（active class）是这样的类，其对象至少拥有一个进程或线程，因此它能够启动控制活动。主动类的对象所表现的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。在图形上，把主动类绘制成类图符，只是它的左右外框是双线，通常它包含名称、属性和操作，如图2-5所示。
【第23章讨论主动类。】
第六，构件（component）是系统设计的模块化部件，将实现隐藏在一组外部接口背后。在一个系统中，共享相同接口的构件可以相互替换，只要保持相同的逻辑行为即可。可以通过把部件和连接件接合在一起表示构件的实现；部件可以包括更小的构件。在图形上，构件的表示很像类，只是在其右上角有一个特殊的图标，如图2-6所示。
【第15章讨论构件和内部结构。】
第七，制品（artifact）是系统中物理的而且可替换的部件，它包括物理信息（“比特”）。在一个系统中，会遇到不同类型的部署制品，如源代码文件、可执行程序和脚本。制品通常代表对源码信息或运行时信息的物理打包。在图形上，把制品画成一个矩形，在其名称的上方标注着关键字«artifact»，如图2-7所示。
【第26章讨论制品。】
第八，结点（node）是在运行时存在的物理元素，它表示一个计算机资源，通常至少有一些记忆能力，还经常具有处理能力。一组构件可以驻留在一个结点内，也可以从一个结点迁移到另一个结点。在图形上，把结点画成一个立方体，通常在立方体中只写它的名称，如图2-8所示。
【第27章讨论结点。】
3．行为事物
行为事物（behavioral thing）是UML模型的动态部分。它们是模型中的动词，代表了跨越时间和空间的行为。共有3类主要的行为事物。
第一，交互（interaction）是这样一种行为，它由在特定语境中共同完成一定任务的一组对象或角色之间交换的消息组成。一个对象群体的行为或者单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作和连接件（对象间的连接）。在图形上，把消息画成一条有方向的直线，通常在其上总是带有操作名，如图2-9所示。
【第17章讨论用于模型中构造行为事物的用况，在第16章讨论交互。】
【第22章讨论状态机。】
第三，活动（activity）是这样一种行为，它描述了计算过程执行的步骤序列。交互所注重的是一组进行交互的对象，状态机所注重的是一定时间内一个对象的生命周期，活动所注重的是步骤之间的流而不关心哪个对象执行哪个步骤。活动的一个步骤称为一个动作。在图形上，把动作画成一个圆角矩形，在其中含有指明其用途的名字，如图2-11所示。状态和动作靠不同的语境得以区别。
4．分组事物
分组事物（grouping thing）是UML模型的组织部分。它们是一些由模型分解成的“盒子”。主要的分组事物是包。
包（package）是用于对设计本身进行组织的通用机制，与类不同，它是用来组织实现构造物的。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件（构件在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在图形上，把包画成带标签的文件夹（一个左上角带有一个小矩形的大矩形），在矩形中通常仅含有包的名称，有时还含有其内容，如图2-12所示。
【第12章讨论包。】
包是用来组织UML模型的基本分组事物。它也有变体，如框架、模型和子系统（它们是包的不同种类）。
5．注释事物
注释事物（annotational thing）是UML模型的解释部分。这些注释事物用来描述、说明和标注模型中的任何元素。有一种主要的注释事物，称为注解。注解（note）是依附于一个元素或一组元素之上对它进行约束或解释的简单符号。在图形上，把注解画成一个右上角是折角的矩形，其中带有文字或图形解释，如图2-13所示。
【第6章讨论注解。】
6．UML中的关系
在UML中有4种关系：
（1）依赖；
（2）关联；
（3）泛化；
（4）实现。
这些关系是UML的基本关系构造块，用它们可以写出形式良好的模型。
第一，依赖（dependency）是两个模型元素间的语义关系，其中一个元素（独立元素）发生变化会影响另一个元素（依赖元素）的语义。在图形上，把依赖画成一条可能有方向的1虚线，有时还带有一个标记，如图2-14所示。
【第5章和第10章讨论依赖。】
第二，关联（association）是类之间的结构关系，它描述了一组链，链是对象（类的实例）之间的连接。聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系。在图形上，把关联画成一条实线，它可能有方向，有时还带有一个标记，而且它还经常含有诸如多重性和端名这样的修饰，如图2-15所示。
【第5章和第10章讨论关联。】
【第5章和第10章讨论泛化。】
第四，实现（realization）是类目之间的语义关系，其中一个类目指定了由另一个类目保证执行的合约。在两种地方会遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用况和实现它们的协作之间。在图形上，把实现关系画成一条带有空心箭头的虚线，它是泛化和依赖关系两种图形的结合，如图2-17所示。
【第10章讨论实现关系。】
7．UML中的图
图（diagram）是一组元素的图形表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样一个图是对系统的投影。对所有的系统（除非很微小的系统）而言，图是系统组成元素的省略视图。有些元素可以出现在所有图中，有些元素可以出现在一些图中（很常见），还有些元素不能出现在图中（很罕见）。在理论上，图可以包含事物及其关系的任何组合。然而在实际中仅出现少量的常见组合，它们与组成软件密集型系统的体系结构的5种最有用的视图相一致。由于这个原因，UML包括13种这样的图：
【在本章后面讨论体系结构的5种视图。】
（1）类图；
（2）对象图；
（3）构件图；
（4）组合结构图；
（5）用况图；
（6）顺序图2；
（7）通信图；
（8）状态图；
（9）活动图；
（10）部署图；
（11）包图；
（12）定时图；
（13）交互概览图。
类图（class diagram）展现了一组类、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出系统的静态进程视图。构件图是类图的变体。
【第8章讨论类图。】
对象图（object diagram）展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
【第14章讨论对象图。】
构件图（component diagram）展现了一个封装的类和它的接口、端口以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的（UML将构件图和适用于任意类的组合结构图区分开来，但由于构件和结构化类之间的差别微不足道，所以一起讨论它们）。
【第15章讨论构件图和内部结构。】
用况图（use case diagram）展现了一组用况、参与者（一种特殊的类）及它们之间的关系。用况图给出系统的静态用况视图。这些图在对系统的行为进行组织和建模上是非常重要的。
【第18章讨论用况图。】
顺序图和通信图都是交互图。交互图（interaction diagram）展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图（sequence diagram）是强调消息的时间次序的交互图；通信图（communication diagram）也是一种交互图，它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念，但每种图强调概念的不同视角，顺序图强调时间次序，通信图强调消息流经的数据结构。定时图（不包含在本书中）展现了消息交换的实际时间。
【第19章讨论交互图。】
状态图（state diagram）展现了一个状态机，它由状态、转移、事件和活动组成。状态图展现了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调由事件引发的对象行为，这非常有助于对反应式系统建模。
【第25章讨论状态图。】
活动图（activity diagram）将进程或其他计算的结构展示为计算内部一步一步的控制流和数据流。活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象间的控制流程。
【第20章讨论活动图。】
部署图（deployment diagram）展现了对运行时的处理结点以及在其中生存的构件的配置。部署图给出了体系结构的静态部署视图。通常一个结点包含一个或多个制品。
【第31章讨论部署图。】
制品图（artifact diagram）展现了计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品常与部署图一起使用。制品也展现了它们实现的类和构件。（UML把制品图视为部署图的变体，但我们分别地讨论它们。）
【第30章讨论制品图。】
包图（package diagram）展现了由模型本身分解而成的组织单元以及它们的依赖关系。
【第12章讨论包图。】
定时图（timing diagram）是一种交互图，它展现了消息跨越不同对象或角色的实际时间，而不仅仅是关心消息的相对顺序。交互概览图（interaction overview diagram）是活动图和顺序图的混合物。这些图有特殊的用法，本书不做讨论，更多的细节可参考The Unified Modeling Language Reference Manual。
并不限定仅使用这几种图，开发工具可以利用UML来提供其他种类的图，但到目前为止，这几种图在实际应用中是最常用的。
2.2.2 UML规则
不能简单地把UML的构造块按随机的方式堆放在一起。像任何语言一样，UML有一套规则，这些规则描述了一个形式良好的模型应该是什么样。形式良好的模型应该在语义上是自我一致的，并且与所有的相关模型协调一致。UML有自己的语法和语义规则，用于：
命名——为事物、关系和图起的名字；
范围——使名字具有特定含义的语境；可见性——这些名字如何让其他成分看见和使用；完整性——事物如何正确、一致地相互联系；执行——运行或模拟一个动态模型意味着什么。在软件密集型系统的开发期间所建造的模型往往需要发展变化，并可以由许多人员以不同的方式、在不同的时间进行观察。由于这个原因，下述的情况是常见的，即开发组不但会建造一些形式良好的模型，也会建造一些像下面这样的模型：省略——隐藏某些元素以简化视图；
不完全——可能遗漏了某些元素；不一致——模型的完整性得不到保证。在软件开发的生命期内，随着系统细节的展开和变动，不可避免地要出现这样一些不太规范的模型。UML的规则鼓励（不是强迫）专注于最重要的分析、设计和实现问题，这将促使模型随着时间的推移而具有良好的结构。2.2.3 UML中的公共机制
通过与具有公共特征的模式取得一致，可以使一座建筑更为简单和更为协调。房子可以按一定的结构模式（它定义了建筑风格）建造成维多利亚式的或法国乡村式的。对于UML也是如此。由于在UML中有4种贯穿整个语言且一致应用的公共机制，因此使得UML变得较为简单。这4种机制是：（1）规约；
（2）修饰；
（3）通用划分；
（4）扩展机制。
1．规约
UML不仅仅是一种图形语言。实际上，在它的图形表示法的每部分背后都有一个规约，这个规约提供了对构造块的语法和语义的文字叙述。例如，在类的图符背后有一个规约，它提供了对该类所拥有的属性、操作（包括完整的特征标记）和行为的全面描述；在视觉上，类的图符可能仅展示了这个规约的一小部分。此外，可能存在着该类的另一个视图，其中提供了一个完全不同的部件集合，但是它仍然与该类的基本规约相一致。UML的图形表示法用来对系统进行可视化；UML的规约用来说明系统的细节。假定把二者分开，就可能进行增量式的建模。这可以通过以下方式完成：先画图，然后再对这个模型的规约增加语义，或直接创建规约，也可能对一个已经存在的系统进行逆向工程，然后再创建作为这些规约的投影的图。
UML的规约提供了一个语义底版，它包含了一个系统的各个模型的所有部分，各部分以一致的方式相互联系。因此，UML的图只不过是对底版的简单视觉投影，每一个图展现了系统的一个特定的关注方面。
2．修饰
UML中的大多数元素都有唯一而直接的图形表示符号，这些图形符号对元素的最重要的方面提供了可视化表示。例如，特意把类的符号设计得容易画出，这是因为在面向对象系统建模中，类是最常用的元素；类的图形符号展示了类的最重要方面，即它的名称、属性和操作。
【第6章讨论注解和其他修饰。】
对类的规约可以包含其他细节，例如，它是否为抽象类，或它的属性和操作是否可见。可以把很多这样的细节表示为图形或文字修饰，放到类的基本矩形符号上。例如，图2-18表示的是一个带有修饰的类，图中表明这个类是一个抽象类，有两个公共操作、一个受保护操作和一个私有操作。
UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上。
3．通用划分
在对面向对象系统建模中，通常有几种划分方式。
第一种方式是对类和对象的划分。类是一种抽象，对象是这种抽象的一个具体表现。在UML中，可以对类和对象建立模型，如图2-19所示。在图形上，UML是这样区分对象的：采用与类同样的图形符号来表示对象，并且在对象名的下面画一道线。
【第13章中讨论对象。】
UML的每一个构造块几乎都存在像类/对象这样的二分法。例如，可以有用况和用况执行、构件和构件实例、结点和结点实例等。
第二种方式是接口和实现的分离。接口声明了一个合约，而实现则表示了对该合约的具体实施，它负责如实地实现接口的完整语义。在UML中，既可以对接口建模又可以对它们的实现建模，如图2-20所示。
【第11章讨论接口。】
几乎每一个UML的构造块都有像接口/实现这样的二分法。例如，用况和实现它们的协作，操作和实现它们的方法。
第三种方式是类型和角色的分离。类型声明了实体的种类（如对象、属性或参数），角色描述了实体在语境中的含义（如类、构件或协作等）。任何作为其他实体结构中的一部分的实体（例如属性）都具有两个特性：从它固有的类型派生出一些含义，从它在语境中的角色派生出一些含义（如图2-21所示）。
UML提供了一种绘制软件蓝图的标准语言，但是一种闭合的语言即使表达能力再丰富，也难以表示出各种领域中的各种模型在不同时刻所有可能的细微差别。由于这个原因，UML是目标开放的，使人们能够以受控的方式来扩展该语言。UML的扩展机制包括：
衍型；
标记值；约束。衍型（stereotype）扩展了UML的词汇，可以用来创造新的构造块，这个新构造块既是从现有的构造块派生的，但是针对专门的问题。例如，假设正在使用一种编程语言，如Java或C++，经常要对“异常事件”建模。在这些语言里，“异常事件”就是类，只是用很特殊的方法进行了处理。通常可能只想允许抛出和捕捉异常事件，没有其他要求。此时可以让异常事件在模型中成为“一等公民”——可以像对待基本构造块一样对待它们，只要用一个适当的衍型来标记它们即可。请看图2-22中的类Overflow。【第6章讨论UML的扩展机制。】
标记值（tagged value）扩展了UML衍型的特性，可以用来创建衍型规约的新信息。例如，如果在制作以盒装形式销售的产品，随着时间的推移，它经过了多次发行，那么经常会想要跟踪产品的版本和对产品做关键摘要的作者。版本和作者不是UML的基本概念，通过引入新的标记值，可以把它们加到像类那样的任何构造块中去。例如，在图2-22中，在类EventQueue上明确标记了版本和作者，这样就对该类进行了扩展。
总的来说，这3种扩展机制允许根据项目的需要来塑造和培育UML。这些机制也使得UML适合于新的软件技术（例如，很可能出现的功能更强的分布式编程语言）。可以增加新的构造块，修改已存在的构造块的规约，甚至可以改变它们的语义。当然，以受控的方式进行扩展是重要的，这样可以不偏离UML的目标——信息交流。
1原文如此。其实UML的依赖关系总是有方向的。——译者注
2将sequence diagram译为顺序图，是本书极个别与国标不一致之处。在制定国标GB/T 11457—2006时，对这种图的名称有“顺序图”和“时序图”两种不同意见，最后定为“时序图”。但是后来UML2.0又定义了另外一种图，即timing diagram，而国内的其他文献又把这种新的图译为“时序图”。于是这两种图的中文译名发生了冲突。为了避免由此引起的术语混乱，本书将它们分别译为“顺序图”和“定时图”。——译者注本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。