PlantUML——类图（一）

PlantUML类图

• • 1、类图的基本概念
  • • 1.1、类图的定义
    • 1.2、类图的作用
  • 2、类图的组成
  • • 2.1、类
    • • 2.1.1、类的名称（Name）
      • 2.1.2、类的属性（Attribute）
      • 2.1.3、类的操作（Operation）
      • 2.1.4、类的职责（Responsibility）
      • 2.1.5、类的约束
      • 2.1.6、类的注解（Note）
    • 2.2、接口
    • 2.3、类之间的关系
    • • 2.3.1、依赖关系（Dependency）
      • 2.3.2、泛化关系（Generalization）
      • 2.3.3、关联关系（Association）
    • 2.3.4、实现关系（Realization）

1、类图的基本概念

类图从抽象的角度描述系统的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类之间的相互关系。

1.1、类图的定义

类图（Class Diagram）显示了系统的静态结构，而系统的静态结构构成了系统的概念基础。系统中的各种概念是在现实应用中有意义的概念，这些概念包括真实世界中的概念、抽象的概念、实现方面的概念和计算机领域的概念。类图，就是用于对系统中的各种概念进行建模，并描绘出它们之间关系的类图。

在大多数的UML模型中，可以将这些概念的类型概括为以下四种，分别是：

• 类
• 接口
• 数据类型
• 构件

并且，UML还为这些类型起了一个特别的名字叫作类元（Classifier）​。类元是对有实例且有属性形式的结构特征和操作形式的行为特征的建模元素的统称。类是一种重要的类元。此外，接口（通常不包含属性）和数据类型（UML1.5规范）以及构件也被认为是重要的类元。在一些关于UML的图书中，也将参与者、信号、节点、用例等包含在内。通常情况下，可以将类元认为是类，但在技术上，类元是一种更为普遍的术语，它还是应当包括其他3种类型。可以说创建类图的目的之一就是显示建模系统的类型。

一个类图通过系统中的类以及各个类之间的关系来描述系统的静态方面。类图与数据模型有许多相似之处，区别就是类不仅描述系统内部信息的结构，还包含系统的内部行为，系统通过自身行为与外部事物进行交互。

在类图中，具体来讲它一共包含以下几种模型元素，分别是：

• 类（Class）
• 接口（Interface）
• 依赖（Dependency）关系
• 泛化（Generalization）关系
• 关联（Association）关系
• 实现（Realization）关系。

并且类图和其他UML中图类似，也可以创建约束、注释和包等。如图所示的类图，它包含了这几种模型元素。

类图中的类可以通过相关语言工具转换成为某种面向对象编程语言的代码。

1.2、类图的作用

由于静态视图主要被用于支持系统的功能性需求，也就是系统提供给最终用户的服务，而类图的作用是对系统的静态视图进行建模。当对系统的静态视图进行建模时，通常是以下列3种方式来使用类图。

• 为系统的词汇建模。使用UML构建系统首先要构造系统的基本词汇，以描述系统的边界。对系统的词汇建模要做出判断：哪些抽象是系统建模中的一部分，哪些抽象是处于建模系统边界之外的。系统分析者可以用类图详细描述这些抽象和它们所执行的职责。类的职责是对该类的所有对象所具备的那些相同属性和操作共同组成的功能或服务进行抽象。
• 模型化简单的协作。现实世界中的事物是普遍联系的，即使将这些事物抽象成类之后，这些类也是具有相关联系的，系统中的类极少能够孤立于系统中的其他类而独立存在，它们总是与其他的类协同工作，以实现强于单个类的语义。协作是由一些共同工作的类、接口和其他模型元素所构成的一个整体，这个整体提供的一些合作行为强于所有这些元素的行为之和。系统分析人员可以通过类图将这种简单的协作进行可视化和描述。
• 模型化逻辑数据库模式。在设计数据库时，通常将数据库模式看作为数据库概念设计的蓝图，在很多领域中，都需要在关系数据库或面向对象的数据库中存储永久信息。系统分析人员可以使用类图来对这些数据库进行建模。

2、类图的组成

类图（Class Diagram）是由类、接口等模型元素以及它们之间的关系构成的。类图的目的在于描述系统的构成方式，而不是系统如何协作运行的。

2.1、类

类是面向对象系统组织结构的核心。类是对一组具有相同属性、操作、关系和语义的事物的抽象。这些事物包括现实世界中的物理实体、商业事务、逻辑事物、应用事物和行为事物等，甚至还包括纯粹的概念性事物。根据系统抽象程度的不同，可以在模型中创建不同的类。

在UML中，类被表述成为具有相同结构、行为和关系的一组对象的描述符号。所用的属性与操作都被附在类中。类定义了一组具有状态和行为的对象。其中，属性和关联用来描述状态。属性通常使用没有身份的数据值来表示，如数字和字符串。关联则使用有身份的对象之间的关系来表示。行为由操作来描述，方法（Method）是操作的具体实现。对象的生命周期则由附加给类的状态机（StateMachine）来描述。

在UML的图形表示中，类的表示法是一个矩形，这个矩形由3个部分构成，分别是：类的名称（Name）​、类的属性（Attribute）和类的操作（Operation）​。

类的名称位于矩形的顶端，类的属性位于矩形的中间部位，而类的操作位于矩形的底部。中间部位不仅描述类的属性，还可以描述属性的类型以及属性的初始化值等。矩形的底部也可以列出操作的参数表和返回类型等。

如图所示，就是一个"Student"类。在类的构成中还应当包含类的职责（Responsibility）​、类的约束（Constraint）和类的注解（Note）等信息。

在Rational Rose 2007中，还可以自定义显示的信息，比如需要隐藏属性或操作以及属性或操作的部分信息等。当在一个类图上画一个类元素时，必须要有顶端的区域，下面的两个区域是可选择的，比如当使用类图仅仅展示出类元之间关系的高层细节时，下面的两个区域就不是必要的。如图所示，隐藏掉了类的属性和操作信息。

2.1.1、类的名称（Name）

类的名称是每个类的图形中所必须拥有的元素，用于同其他类进行区分。类的名称通常来自于系统的问题域，并且尽可能地明确表达要描述的事物，不要造成类的语义冲突。类的名称应该是一个名词，且不应该有前缀或后缀。按照UML的约定，类的名称的首字母应为大写，如果类的名称由两个单词组成，那么将这两个单词合并，第二个单词的首字母也为大写。类的名称的书写字体也有规范，正体字说明类是可被实例化的，斜体字说明类为抽象类。如图所示，代表的是一个名称为"Transportation"的抽象类。

类在它的包含者内有唯一的名字，这个包含者通常可能是一个包，但也可能是另外一个类。包含者对类的名称也有一定的影响。在类中，默认显示包含该类所在的包的名称。

如图所示，代表一个名称为"Printer"的类位于名称为"Office"的包中。在一些关于UML的书中，也可以表示成"Office：​：Printer"这种形式，将类的名称分为简单名称和路径名称。单独的名称（即不包含冒号的字符串）就叫作简单名（Simple Name）​。用类所在的包的名称作为前缀的类名就叫作路径名（Path Name）​。

2.1.2、类的属性（Attribute）

属性是类的一个特性，也是类的一个组成部分，描述了在软件系统中所代表的对象具备的静态部分的公共特征的抽象，这些特性是这些的对象所共有的。当然，有时，也可以利用属性值的变化来描述对象的状态。一个类可以具有零个或多个属性。

在UML中，类的属性的表示语法为（​​内的内容是可选的）​：

[可见性] 属性名称 [：属性类型]  [=初始值] [{属性字符串}]

例如，在上面列举的"Student"类的属性见表所示。

可见性：

属性的可见性描述了该属性是否对于其他类可见，是否可以被其他类引用。类中属性的可见性包含3种，分别是公有类型（public）​、受保护类型（protected）和私有类型（private）​。在Rational Rose 2007中，类的属性设置中添加了Implementation选项。如表所示，列出了在Rational Rose 2007中类的属性的可见性可以设置的类型。

属性名称：

属性是类的一部分，每个属性都必须有一个名字以区别于类中的其他属性。通常情况下，属性名由描述所属类的特性的名词或名词短语构成。按照UML的约定，属性名称的第一个字母小写，如果属性名中包含了多个单词，这些单词要合并，并且除了第一个英文单词外其余单词的首字母要大写。

属性类型：

属性也具有类型，用来指出该属性的数据类型。典型的属性类型包括Boolean、Integer、Byte、Date、String和Long等，这些被称为简单数据类型。虽然这些简单数据类型在不同的编程语言中有所区别，但是各种编程语言基本上都会支持这些简单数据类型。在UML中，类的属性可以是任意的类型，包括系统中定义的其他类。当一个类的属性被完整定义后，它的任何一个对象的状态都由这些属性的特定值所决定。

初始值：

在程序设计中，设置初始值通常有两个用处：

1. 用来保护系统的完整性。在编程过程中，为了防止漏掉对类中某个属性的取值，或者类的属性在自动取值的时候会破坏系统的完整性，就可以通过赋初始值的方法来保护系统的完整性；
2. 为用户提供易用性。设置一些初始值能够有效帮助用户进行输入，从而为用户提供良好的易用性。

属性字符串：

属性字符串是用来指定关于属性的一些附加信息，比如某个属性应该在某个区域是有限制的。任何希望添加在属性定义的字符串中但又没有合适的地方可以加入的规则，都可以放在属性字符串中。

2.1.3、类的操作（Operation）

操作指的是类所能执行的操作，也是类的一个重要组成部分，描述了在软件系统中所代表的对象具备的动态部分的公共特征的抽象。类的操作可以根据不同的可见性由其他任何对象调用。属性是描述类对象特性的值，而类的操作用于操纵属性的值进行改变或执行其他动作。类的操作有时被称为函数或方法，在类的图形表示中它们位于类的底部。一个类可以有零个或多个操作，并且每个操作只能应用于该类的对象。

操作由一个返回类型、一个名称以及参数表来描述。其中，返回类型、名称和参数一起被称为操作签名（Signature of the Operation）​。操作签名描述使用该操作所必需的所有信息。在UML中，类的操作的表示语法为（​ 内的内容是可选的）​：

[可见性] 操作名称 [（参数表）]  [：返回类型] [{属性字符串}]

例如，在上面例子中的"Student"类的操作如表所示。返回类型Boolean

可见性：

操作的可见性描述了该操作是否对于其他类可见，是否可以被其他类所调用。类中操作的可见性一般包含3种，分别是公有类型（public）​、受保护类型（protected）和私有类型（private）​。在Rational Rose 2007中，类的操作设置中添加了Implementation选项。如表所示，列出了在Rational Rose 2007中类的属性的可见性可以设置的类型。

在Rational Rose 2007中，类的操作选择上面四种类型的任意一种，默认的情况为公有类型，即public类型。

操作名称：

操作作为类的一部分，每个操作都必须有一个名称以区别于类中的其他操作。通常情况下，操作名由描述所属类的行为的动词或动词短语构成。和属性的命名一样，操作的名称的第一个字母小写，如果操作的名称中包含多个英文单词，那么这些单词需要进行合并，并且除第一个英文单词之外其余单词的首字母都要大写。

参数表：

参数表就是由类型、标识符组成的序列，实际上是操作或方法被调用时接收传递过来的参数值的变量。参数的定义方式采用"名称：类型"的定义方式，如果存在多个参数，则将各个参数用逗号分隔开。如果方法没有参数，则参数表为空。参数可以具有默认值，也就是说如果操作的调用者没有为某个具有默认值的参数赋值，那么该参数将使用指定的默认值。

返回类型：

返回类型指定了由操作返回的数据类型。它可以是任意有效的数据类型，包括我们所创建的类的类型。绝大部分编程语言只支持一个返回值，即返回类型只有一个。如果操作没有返回值，在具体的编程语言中一般要加一个关键字void来表示，也就是其返回类型必须是void。

属性字符串：

属性字符串是用来附加一些关于操作的除了预定义元素之外的信息，方便对操作的一些内容进行说明。

2.1.4、类的职责（Responsibility）

在标准的UML定义中，有时还应当指明类的另一种信息，那就是类的职责。类的职责指的是对该类的所有对象所具备的那些相同属性和操作所共同组成的功能或服务的抽象。类的属性和操作是对类的具体结构特征和行为特征的形式化描述，而职责是对类的功能和作用的非形式化描述。有了属性、操作和职责，一个类的重要语义内容基本就定义完毕了。

在声明类的职责时，可以非正式地在类图的下方增加一栏，将该类的职责逐条描述出来。类的职责的描述并不是必须的，因此也可以将其作为文档的形式存在，也就是说类的职责其实只是一段或多段文字的描述。一个类可以有多种职责，设计好的类一般至少有一种职责。

2.1.5、类的约束

类的约束指定了该类所要满足的一个或多个规则。在UML中，约束是用一个大括号括起来的文本信息。

在使用Rational Rose 2007表达类与类之间的关联时，通常会对类使用一些约束条件。如图所示，指出在"Teacher"类和"Printer"类应当满足的约束。

2.1.6、类的注解（Note）

使用注解可以为类添加更多的描述信息，也是为类提供更多的描述方式中的一种。如图所示。

2.2、接口

接口是在没有给出对象的实现和状态的情况下对对象行为的描述。通常，在接口中包含一系列操作但是不包含属性，并且它没有对外界可见的关联。可以通过一个或多个类或构件实现一个接口，并且在每个类中都可以实现接口中的操作。

接口是一种特殊的类，所有接口都是有构造型<<interface>>的类。一个类可以通过实现接口从而支持接口所指定的行为。在程序运行的时候，其他对象可以只依赖于此接口，而不需要知道该类对接口实现的其他任何信息。一个拥有良好接口的类具有清晰的边界，并成为系统中职责均衡分布的一部分。

在UML中，接口的表示方式为使用一个带有名称的小圆圈，并且可以通过一条Realization（实现关系）线与实现它的类相连接，如图所示。

当接口被其他类依赖时，也就是说在一个接口在某个特定类中实现后，类通过依赖关系与该接口相连接。这时，依赖类仅仅依赖于指定接口中的那些操作，而不依赖于接口实现类中的其他部分。在依赖类中可以通过一些方式调用接口中的操作。这种关系如图所示。

接口也可以像类那样进行一般化和特殊化处理。在类图中，接口之间的泛化关系也是用类泛化关系所使用的符号来表示，如图所示。

2.3、类之间的关系

类与类之间的关系最常用的有四种关系，它们分别是依赖关系（Dependency）​、泛化关系（Generalization）​、关联关系（Association）和实现关系（Realization）​，如表所示。

2.3.1、依赖关系（Dependency）

依赖关系表示的是两个或多个模型元素之间语义上的连接关系。它只将模型元素本身连接起来而不需要用一组实例来表达它的意思。它表示了这样一种情形，提供者的某些变化会要求或指示依赖关系中客户的变化。也就是说依赖关系将行为和实现与影响其他类的类联系起来。

根据这个定义，关联关系包括很多种，除了实现关系以外，还可以包含其他几种依赖关系，包括跟踪关系（不同模型中元素之间的一种松散连接）​、精化关系（两个不同层次意义之间的一种映射）​、使用关系（在模型中需要另一个元素的存在）​、绑定关系（为模板参数指定值）​。关联和泛化也同样都是依赖关系，但是它们有更特别的语义，故它们有自己的名字和详细的语义。我们通常用依赖这个词来描述其他的关系。

使用依赖关系还经常用来表示具体实现间的关系，如代码层的实现关系。在概括模型的组织单元（例如包）时依赖关系很有用，它在其上显示了系统的构架。例如编译方面的约束可通过依赖关系来表示，如表所示。

这些依赖关系具体来讲可以再分为五种类型，分别是绑定（Binding）依赖、实现（Realization）依赖、使用（Usage）依赖、抽象（Abstraction）依赖和授权（Permission）依赖。

绑定（Binding）依赖

绑定（Binding）依赖只包含绑定关系。绑定是将数值分配给模板的参数。它是具有精确语义的高度结构化的关系，可通过取代模板备份中的参数来实现。使用和绑定依赖在同一语义层上将很强的语义包括进元素内，它们必须连接模型同一层的元素（或者都是分析层，或者都是设计层，并且在同一抽象层）​。

跟踪和精化依赖更模糊一些，可以将不同模型或不同抽象层的元素连接起来。

访问依赖允许一个客户访问提供者内的元素，但是客户必须使用提供者的路径名称。通过这种方式，在一个包中的类可以访问在其他包中的类。

实现（Realization）依赖

实现（Realization）依赖指的是说明和这个说明的具体实现之间的映射关系

使用（Usage）依赖

使用（Usage）依赖都是非常直接的，通常表示客户使用提供者提供的服务来实现自身的行为。使用依赖关系包含使用、调用、参数、发送和实例化等依赖关系。使用表示的是一个元素的行为或实现会影响另一个元素的行为或实现；

• 调用表示一个类中的方法或操作调用另一个类的方法或操作；
• 参数表示类中的一个操作和它的参数之间的关系。
• 发送表示一个类中的方法把信号发送到相关接收目标；
• 实例表示一个类的方法创建了另一个类的实例。

抽象（Abstraction）依赖

抽象（Abstraction）依赖用来表示客户与提供者之间的关系，依赖于不同抽象层次上的事物，将同一个潜在事物的不同形式联系起来。抽象依赖关系包含跟踪、精化和派生等依赖关系。

跟踪是对不同模型中元素连接的概念表述，通常这些模型是开发过程中不同阶段的模型。跟踪缺少详细的语义，它特别用来追溯跨模型的系统要求，并跟踪会影响其他模型的模型所起的变化。

精化是表示位于不同的开发阶段或处于不同的抽象层次中的一个概念的两种形式之间的关系。这并不意味着两个概念会在最后的模型中共存，它们中的一个通常是另一个的未完善的形式。原则上，在较不完善到较完善的概念之间有一个映射，但这并不意味着它们之间的转换是自动的。通常情况，更详细的概念包含着设计者的设计决定，而决定可以通过许多途径来做出。原则上讲，对一个模型的改变可被另一个模型所替换。实际上，虽然一些简单的映射可以实现，但是现有的工具不能完成所有这些映射。因此精化通常提醒建模者多重模型以可预知的方式发生相互转换的关系。

派生表示一个元素可以通过计算另一个元素来获得（而被派生的元素可以明确包含在系统中以避免花费太多代价进行迭代计算）​。

授权（Permission）依赖

授权（Permission）依赖用来表示一个事物对另外一个事物进行访问的能力。提供者通过设定客户类的相关权限，控制和限制对其内容访问的方法。授权依赖关系包含访问、导入、友元等依赖关系。访问是允许一个包引用另一个包中的元素；导入指的是提供者包中的元素名称被加入到客户包的命名空间中；友元是指允许客户访问提供者的内容，即使客户没有足够的访问提供者的可见性。

依赖关系使用一个从客户指向提供者的虚箭头来表示，并且使用了一个构造型的关键字并将它位于虚箭头之上来区分依赖关系的种类，如图所示。在图中"ClassA"表示的是客户，​"ClassB"表示的是提供者，​"<<use>>"是构造型关键字，表示使用依赖关系。

2.3.2、泛化关系（Generalization）

泛化关系是用来描述类的一般和特殊（或具体）之间的关系。特殊描述建立在对类的一般描述的基础之上，并对其进行了扩展。因此，在特殊描述中不仅包含一般描述中所拥有的所有特性、成员和关系，而且还包含了特殊描述补充的信息。例如，小汽车、客车都是交通工具中的一种。

在泛化关系中，一般描述的类被称为父类，特殊描述的类被称为子类。例如，交通工具可以被抽象成是父类，而小汽车、客车则通常被抽象成子类。泛化关系还可以在类元（类、接口、数据类型、用例、参与者、信号等）​、包、状态机和其他元素中使用。在类中，术语超类和子类是父类和子类的另外一种说法。

泛化关系使用从子类指向父类的一个带有实线的箭头来表示，指向父类的箭头是一个空心三角形，如图所示，交通工具为父类，汽车为子类。多个泛化关系可以用箭头线组成的树形结构来表示，每一个分支指向一个子类。

2.3.3、关联关系（Association）

关联关系是一种结构关系，它指出了一个事物的对象与另一个事物的对象之间在语义上的连接。关联关系描述了系统中对象或实例之间的离散连接，它将一个含有两个或多个有序表的类，在允许复制的情况下连接起来。一个类关联的任何一个连接点都叫关联端，与类有关的许多信息都附在它的关联端的端点上。关联端有名称、角色、可见性以及多重性等特性。

关联关系的一个实例被称为链。链即所涉及对象的一个有序表，每个对象都必须是关联关系中对应类的实例或此类后代的实例。系统中的链组成了系统的部分状态。链并不独立于对象而存在，它们从与之相关的对象中得到自己的身份（在数据库术语中，对象列表是链的键）​。

最普通的关联关系是一对类之间的二元关联关系。二元关联关系使用一条连接两个类的连线表示。如图所示，连线上有相互关联的角色名而多重性则加在各个关联端的端点上。

由于类是抽象的，因此类也可以与它本身相关联。如图所示，这是一个Employee类通过"manager /manages"角色与它本身相关。当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。

如果一个关联既是类又是关联，那么它是一个关联类，如图所示，​"NewClass3"便是一个关联类。

如果一个关联的属性在一组相关对象中是唯一的，那么它是一个限定符。限定符是用来在关联中从一组相关对象中标识出的独特对象的值。限定符对建模名字和身份代码是很重要的，同时它也是设计模型的索引。如图所示，​"name:Boolean"就是限定符。

关联关系还有两种非常重要的形式，分别是聚合（Aggregation）关系和组合（Composition）关系。

聚合（Aggregation）关系描述的是部分与整体关系的关联，简单地说，它将一组元素通过关联组成一个更大、更复杂的单元，这种关联关系就是聚合。聚合关系描述了"has a"的关系。在UML中，它用端点带有空菱形箭头的线段来表示，空菱形箭头与聚合类相连接，其箭头的头部指向整体。如图所示，表示"NewClass1"和"NewClass2"的聚合关系，其中在"NewClass1"中包含"NewClass2"​。

组合（Composition）关系则是一种更强形式的关联，在整体中拥有管理部分特有的职责，有时也被称为强聚合关系。在组合中，成员对象的生命周期取决于聚合的生命周期，聚合不仅控制着成员对象的行为，而且控制着成员对象的创建和终结。在UML中，组合关系使用带实心菱形箭头的实线来表示，其中箭头头部指向整体。如图所示，表示主机与CPU、主板之间的组合关系，其中"主机"类中包含"CPU"类和"主板"类，​"CPU"类和"主板"类不能脱离"主机"类而存在。

在Rational Rose 2007中对关联关系进行表示中，还有几种特性应用于关联端来修饰关联关系，它们分别是名称、角色、多重性、构造型和导航性等。

名称：

关联关系可以有自己的名称，用来描述关系的性质。通常情况下，使用一个动词或动词短语来命名关联关系，以表明源对象在目标对象上执行的动作。如图所示。

关联的名称并不是必需的，只有在需要明确地给出关联角色名，或者一个模型存在很多关联需要查阅和区别这些关联关系时，才有必要给出关联的名称。

角色：

角色指的是在关联关系中，一个类通过关联描述出对另外一个类的职责。当类出现在关联的一端时，该类就在关联关系中扮演一个特定的角色。角色的名称是名词或名词短语，以解释对象是如何参与关系的。如果类与它本身进行关联，也可以设定角色，如图6-19所示，关联的角色为"manager / manages"​，也就是说，​"Employee"类既可以扮演"manager"的角色，也可以扮演"manages"的角色。

多重性：

多重性是指在关联关系中，一个类的多个实例与另外一个类的一个实例相关。关联端可以包含有名字、角色名和可见性等特性，但是最重要的特性则是多重性，多重性对于二元关联关系很重要，因为定义n元关联关系很复杂。多重性可以用一个取值范围、特定值、无限定的范围或一组离散值来描述。

在UML中，多重性是使用一个"..."和分开的两个数值区间来表示的，其格式为"minimum...maximum"​，其中minimum和maximum都是整数。当一个端点给出多少值时，就表示该端点可以有多个对象与另一个端点的一个对象进行关联。

构造型：

在关联关系中也可以根据具体的语义设置一些构造型，在Rational Rose 2007中，默认设置的构造型包含communicate、extend、include、realize和subscribe等，也可以自己进行设置。如图所示，是一个设置构造型为subscribe的关联。

导航性：

关联的导航性描述的是一个对象通过链（关联的实例）对另一个对象进行导航访问，对一个关联端点设置导航意味着本端的对象可以被另一端的对象访问。导航也根据方向的不同划分为单向关联（Unidirectional Association）和双向关联（Bidirectional Association）​。单向关联指的是只能在一个方向上进行导航的关联，通常使用一条带箭头的实线来表示。如图6-25所示，是一种单向关联。而双向关联指的是可以在两个方向上都导航的关联，通常使用一条没有箭头的实线来表示。如图所示，是一种双向关联。

2.3.4、实现关系（Realization）

实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来，用于说明和实现之间的关系。在实现关系中，接口只是行为的描述或说明而不包含实现，而类中则要包含具体的实现内容，可以通过一个或多个类实现一个接口，但是每个类必须分别实现接口中的操作或方法。虽然实现关系意味着要有像接口这样的元素，它也可以用一个具体的实现元素来暗示它的描述（而不是它的实现）必须被支持。例如，这可以用来表示类的一个优化形式和一个简单形式之间的关系。

在UML表示中，实现关系的表示符号和泛化关系的表示符号很相像，使用一条带空三角形箭头的虚线来表示，如图所示，接口类为"ClassA"​，具体的实现类为"ClassB"​。

在UML中，接口使用一个圆圈来表示，并通过一条实线连接到代表类的矩形上来表示实现关系，如图所示，表示"ClassA"类实现了"InterfaceA"和"InterfaceB"接口。