2.4 UML 2概念模型

UML 2规范按照语义结构组织，详细阐述了各类模型元素的语法结构，然而规范中的介绍面面俱到，普通用户很多时候只使用那些最常用的属性，例如图2-2中有关类结构中的内部类就很少使用。因此，对于普通建模用户来说，更多的还是从业务角度考虑问题，例如为目标系统建模，需要哪些建模元素、涉及哪些基本概念等。这些核心概念形成了UML的概念模型。开发人员通过概念模型掌握UML建模的基本思想，从而能够读懂并建立一些基本模型；当有了丰富的应用UML的经验时，开发人员就能够在这些概念模型之上理解UML 2结构，从而使用更深层次的语言特征开展构造工作。

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

2.4.1 构造块

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

1．事物

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

（1）结构事物（Structural Thing）是UML模型中的名词。它们通常是模型的静态部分，用于描述概念元素或物理元素。常见的结构事物包括类、接口、用例、协作、构件、工件、节点等。在以后应用的时候，我们会对大部分概念做详细讲解，也可以参考其他UML参考书籍。

（2）行为事物（Behavioral Thing）是UML模型中的动词。它们是模型的动态部分，代表了跨越时间和空间的行为。常见的行为事物包括交互、状态机、活动等。

（3）分组事物（Grouping Thing）是UML模型的组织部分，用于将模型元素组织在一起。主要的分组事物是包，还有其他的诸如子系统、层等基于包的扩展事物。

（4）注释事物（Annotational Thing）是UML模型的解释部分，用来描述、说明和标注模型的任何元素。最重要的注释事物就是注解（Note），它是依附于一个元素或一组元素之上对元素进行约束或解释的简单符号，所有的UML图形元素均可以用注解来说明。

2．关系

关系将UML的事物连接起来，构造出结构良好的UML模型。在UML中有4种基本关系：依赖、关联、泛化和实现。图2-5列出了这4种关系的图形表示符号。

（1）依赖（Dependency）是两个事物间的弱语义关系，表明两个事物之间存在着一种使用关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。依赖关系的箭头表明了依赖的方向，即没有箭头端的事物依赖于有箭头端的事物。

（2）关联（Association）是一种强语义联系的结构关系，表明两个事物之间存在着明确的、稳定的语义联系。它描述了一组链接（link），链接是事物的具体实例之间的关联（如类之间的关联，则意味着类的对象之间存在链接）。聚合（Aggregation）是一种特殊类型的关联，它表明关联的两个事物之间还存在一种整体和部分的语义联系。图2-5中的关联关系两端都没有标注箭头，这并不意味着关联关系没有方向，默认情况下关联的方向是双向的，也就是说，两个关联的事物之间互相依赖。如果要标注单方向的依赖，则需要在关联的一端标注箭头。有关关联关系的方向问题，将在第9.3.7小节进行详细介绍。

（3）泛化（Generalization）是一种特殊—一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。通过这种关系，子元素共享了父元素的结构和行为（参见第1.4.3小节）。

（4）实现（Realization）是两个事物之间的一种契约关系，其中的一个事物（箭头指向的事物）描述了另一个事物必须实现的契约。在两种位置会遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。

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

3．图

在所有UML CASE工具中，当用户创建了新事物或者新关系时，它们就被加入模型中。模型是所有事物和关系的知识库，创建模型有助于描述正在设计的软件系统的所需行为。模型中有很多元素、元素之间有很多关系，这些都需要展示给用户，这种展示就是通过UML的图来实现的。

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

UML 2提供了14种不同类型的图（UML 1.x中为9种），如图2-4所示。需要说明的是，此处图的分类是根据UML 2.5规范的附录A给出来的。在UML 2.5中还给出了信息流图（Information Flow Diagram）的元模型，但目前这种图形并没有被确定为一种独立的图形而放入这个分类中。此外，还有诸如行为状态机图、协议状态机图、模型图、内部结构图等一些现有图的子图，这些图形也都没有放入分类。因此，本书还是围绕UML 2之前版本的14种图来介绍。

针对这14种图，按照UML 2.5的分类方法可以划分成两类：一类描述系统的静态结构模型；另一类描述系统的动态行为模型。结构模型捕获事物及事物之间的静态关系，而行为模型则捕获事物是如何交互以产生软件系统所需的行为。有关各类UML图的使用，我们将在第2.5节中结合具体的案例进行系统的介绍，并且在后续章节中会对一些重要图形的使用方法进行详细论述。

2.4.2 通用机制

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

（1）规格说明（Specifications）：文本维度的模型描述。

（2）修饰（Adornments）：描述建模元素的细节信息。

（3）通用划分（Common Divisions）：建模时对事物的划分方法。

（4）扩展机制（Extensibility Mechanisms）：用于扩展UML建模元素，包括构造型、约束和标记值3类机制。

1．规格说明

UML不仅仅是一种图形语言，实际上，在UML表示法的每部分背后都有一个文本维度的规格说明，这个规格说明提供了对构造块的语法和语义的文字叙述。例如，在一个类图符背后就有一个规格说明，它提供了对该类所拥有的属性、操作（包括完整的特征标记）和行为的全面描述；而在视觉上，类图符可能仅展示了这个规格说明的一小部分。此外，还可能存在着该类的另一个视图，其中提供了一个完全不同的部件集合，但是它仍然与该类的基本规格说明相一致。

UML的规格说明承载模型的语义背板，它包含了一个系统的各模型的所有部分，而且各部分相互联系，并保持一致。因此，UML的图只不过是对背板的简单视觉投影，每一个图展现了系统的一个特定的方面。

使用UML建模，通常是开始于一个主要的图形模型，它允许用户可视化系统；然后，随着模型演化，向背板中加入越来越多的语义。然而，对于任何一个有价值的或者完整的模型，在背板中必须存在模型语义，否则这些图形仅仅是由线所连接的无意义方框的集合。实际上，新手所犯的常见错误可能被称作“因图形而死亡”——模型被过度图形化而没有文本说明。

2．修饰

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

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

3．通用划分

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

第一种是类元（Classifier）和实例的划分。类元表示一种抽象，实例则是这种抽象的一个具体表现。在UML中，很多概念都是基于这种划分方法建立的，例如，类和对象、用例和场景、构件和构件实例等。

第二种是接口和实现的分离。接口声明行为的契约（做什么），实现表示对该契约的具体实现细节（如何做）。例如，接口和子系统、用例和用例实现、操作和方法等。

第三种是类型和角色的分离，这是UML 2新增的划分方法。类型声明实体的种类（如对象、属性、参数），而角色描述实体在语境（如类、构件、协作、组合结构）中的含义。任何作为其他实体结构的一部分实体（如属性）都具有两个方面的特性：从固有类型派生出来的含义和在语境中的角色派生出来的含义。图2-7展示了组合结构中的customer对象，作为Person类，customer对象具有Person类所提供的属性和行为；同时，作为组合结构TickOrder（订票系统）中的角色，customer是一个订票的顾客。

4．扩展机制

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

（1）构造型（Stereotype）：基于已有的建模元素引入新的建模元素。

（2）标记值（Tagged Value）：扩展UML构造型的特性，可以用来创建构造型的详细信息。

（3）约束（Constraint）：扩展UML构造块语义，可以用来增加新的规则或修改现有规则。

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

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

5．外廓和外廓图

随着UML应用的日益广泛，UML 2标准所定义的元素不一定能够满足特定应用场景的需求，为此需要利用扩展机制对UML 2进行扩展或裁减。而在不同的应用领域，可以有不同扩展，例如针对实时嵌入式领域，可以定义一组特定的构造型、元类等，以描述实时、安全、可靠性等一般应用中不需要考虑的特征。这一组扩展机制就形成了UML的外廓。

外廓（Profile）是基于UML元素的子集为特定领域定义UML的一个特定版本，即定义了一组对UML已有模型的扩展和限定机制，以用于某个特定领域。这些扩展和限定机制包括：预定义的构造型、标记值、约束、基类等。外廓是建立在普通的UML元素基础上，是对UML标准的裁剪和扩展，并不代表一种新的建模语言。针对一些常用的应用领域，OMG推出了一些标准的扩展，如用于实时嵌入式建模的MARTE（UML Profile for Modeling and Analysis of Real-time and Embedded Systems）、用于测试的UML Testing Profile、用于硬件设计的UML Profile for System on a Chip等。

为了便于用户定义外廓，自UML 2.3起，UML标准新增了外廓图。外廓图（Profile Diagram）是一种用于描述UML扩展机制的结构图。用户可以针对不同的平台（如Java EE、.NET等）或领域（如实时嵌入式领域、业务建模领域、测试领域、硬件设计领域等）定义符合UML元模型的扩展内容。表2-1列出了外廓图中的主要元素及其图形表示。

为了便于理解外廓图的应用，下面以扩展UML类图以用于数据库建模为例，说明具体的扩展过程。

数据库建模的核心概念是表、字段和关系等，这些概念在UML标准规范中并没有定义，无法直接利用UML建模。为此，我们需要通过扩展UML类图中的相关概念，如可以利用UML类建模表，利用类的属性建模表的字段，利用类之间的关联关系来建模实体间的关系。这里，我们利用外廓图定义了3个构造型MyTable、MyColumn和MyRelationship，分别表示数据库表、字段和关系，它们各自从UML元类中的类（Class）、属性（Attribute）和关联关系（Association）上扩展而来；此外，对于MyColumn构造型，我们还添加了两个布尔类型的标记值PK和IsNULL，分别表示该字段是否为主键（默认值为false）、是否可以为空（默认值为true）。定义这套扩展机制的外廓图如图2-10所示。需要说明的是，该图采用Enterprise Architect绘制，图中3个扩展的构造型没有采用表2-1中的标准表示形式（即名称前面加“<<stereotype>>”的方式），而是采用右上角添加“《》”的方式表示，这是该建模工具所提供的特定图形符号。

在定义这个用于数据库建模的外廓后，即可以借助UML类图进行数据库建模。图2-11列出了两个简单的数据库表的建模示例，这是一个UML类图，但通过前面定义的3个构造型即可以进行数据库表结构和关系的表示。需要注意的是，MyColumn构造型的标记值可以通过建模工具提供的手段设置相应的值，但该图中并没有可视化展现出来（这依赖于建模工具的支持）。例如在Enterprise Architect中，通过属性设置中单独的标记值（Tagged Values）属性也可以设置具体的标记值，图2-12列出的是Student表中StuNo字段的两个标记值的设置情况截图，可以看出，其PK设置为true, IsNull设置为false，这表明StuNo字段是这个表的主键，同时不允许为空。

2.4.3 架构

UML提供了丰富的模型图来表达系统的各个方面，这些图形之间并不是完全独立的，它们之间存在着千丝万缕的联系。在软件开发的各个阶段，每种图形都有不同的用法和侧重点，这就给普通用户的使用带来了很大的困扰。

UML标准只是提出了这些图形的语法模型和语义模型，并没有针对这些图形的使用提供很好的支持。为了有效地利用这些模型，我们就需要结合不同的软件工程过程，定义组织图形的架构。

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

在这种架构中一共提供了5个视图（View）来组织UML模型，每个视图面向不同的用户，提供不同的UML模型，以实现不同的建模目标。视图可以理解为系统在某个视角的模型，正如前面在“建模的基本原则”中提到的，往往需要从多个视角建立不同的模型，而这些视角就构成了UML建模的基本架构，也将知道后续的建模活动。

◆ 用例视图（Use-Case View）：建模过程的起点和依据，面向最终用户，描述系统的功能性需求。所有其他视图都是从用例视图派生而来的，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础。

◆ 逻辑视图（Logical View）：面向系统分析和设计人员，描述软件结构。它来自功能需求，用于描述问题域的结构。作为类和对象的集合，它的重点是展示对象和类是如何组成系统、实现所需系统行为的。

◆ 进程视图（Process View）：面向系统集成人员，描述系统性能、可伸缩性、吞吐量等信息。其目标是为我们系统中的可执行线程和进程建模，使它们作为活动类。事实上，它是逻辑视图面向进程的变体，包含所有相同的工件。

◆ 实现视图（Implementation View）：面向编码人员，描述系统的组装和配置管理。其目标是对组成基于系统的物理代码的文件和构件进行建模。

◆ 部署视图（Deployment View）：面向系统工程师，描述系统的拓扑结构、分布、移交、安装等信息。建模的目标是把组件物理地部署到一组物理的、可计算的节点（如计算机）上。

使用Rational Rose建模工具的用户，在开始一个新项目后，在默认情况下将提供这些视图（有些细节并不一致，如默认不提供进程视图，因为这些视图本质上是逻辑视图的变体），用户按照这些视图的组织结构逐步完成整个建模过程。

除了“4+1”架构视图外，很多UML工具还提供了其他的模型组织架构。例如，当使用Enterprise Architect新建UML模型时，建模向导可以帮助开发人员建立基本的模型结构，并提供相应的视图。有时候，甚至可以按照系统的开发阶段或活动来组织模型。按照在第3.1.1小节中所定义的UML分析设计过程，可以定义如图2-14所示的UML架构。

该架构采用Enterprise Architect建模，按照开发阶段划分模型（其中“06．部署模型”在设计阶段的架构设计中完成，在开发后的部署阶段使用），与本书后面的章节内容对应。读者也可以参照这个架构组织自己的模型。