UML--静态建模：类和类图

       用面向对象的方法处理实际问题时，需要建立面向对象的模型。构成面向对象模型的基本元素有类（class）、对象（objects）、类与类之间的关系等等。用面向对象的思想描述问题，能够把复杂的系统简单化、直观化，而且易于用面向对象语言编程实现，还方便日后对系统的维护工作。

4.1类和对象

         所谓对象就是可以控制和操作的实体，它可以是一个设备，一个组织或一个商务。类是对象的抽象描述，它包括属性的描述和行为的描述两方面。属性描述类的基本特征（比如，车身的长度、颜色等）；行为描述类具有的功能（比如，汽车有启动、行使、制动等功能），也就是对该类的对象可以进行哪些操作。就像程序设计 语言中整型变量是整数类型的具体化，用户可以对整型变量进行操作（并不是对整数类型操作）一样，对象是类的实例化，所有的操作都是针对对象进行的。

         在计算机系统中，我们用类表示系统，并把现实世界中我们能够识别的对象分类表示，这种处理方式称作面向对象。由于面向对象的思想与现实世界中的事物的表示方式相似，所以采用面向对象的思想构建模型会给建模者带来很多好处。

         当建模者创造一个商务系统、信息系统或其他系统的时候，如果用于描述模型的一些概念与问题域中的概念一致那么这个模型就易于理解，易于交流。比如，为保险公司的业务系统建模，那么一定要使用保险业务中的概念，否则，很难将对象之间的业务关系描述清楚。把系统建立在某个商务的基本概念之上的另一个重要原因是：易于维护系统。因为当新的法规、政策、条款等出台后，建模者必须重新建模使之适应新的变化，由于模型是建立在对象基础上，所以修改模型并不费力，只要把新商务与旧商务之间的不同之处重新设计描述一下即可，其他地方并不需要修改或调整。由此可以看出，以面向对象方式建造的模型，由于建造在真实世界的基本概念上，与真实世界非常接近，使得该模型易于交流，易于验证（检查功能需求），易于维护。反过来说，在各种不同的建模方法中（比如，面向对象、面向过程、面向数据），若模型需要反映真实世界中问题域的基本概念，那么面向对象的方法是最好的选择。

4.2类图

         类图是用类和它们之间的关系描述系统的一种图示，是从静态角度表示系统的，因此类图属于一种静态模型。类图是构建其他图的基础，没有类图，就没有状态图、协作图等其他图，也就无法表示系统的其他各个方面。

         类图中允许出现的模型元素只有类和它直接的关系。类用长方形表示，长方形分成上、中、下三个区域，每个区域用不同的名字标识，用以代表类的各个特征，上面的区域内用黑体字标识类的名字，中间的区域内标识类的属性，下面的区域内标识类的操作方法（即行为），这三个部分作为一个整体描述某个类。当类图中存在多个类时，类与类之间的关系可以用表示 某种关系的连线（比如直线、虚线等），把它们连接起来。类图的另一种表示是用类的具体对象替代类，这种表示方法是类图的变种，称作对象图。

 

         在类图中，类被图示为一个长方形，而在具体程序实现时，类可以用面向对象语言（比如，c++、java语言）中的类结构描述，对类结构的描述包括属性的描述和操作描述。

4.2.1定义类

         在进行构造类图描述系统的工作时，首先要定义类，也就是将系统要处理的数据抽象成类的属性，将处理数据方法抽象为操作。要准确的找到类不是一件容易的事，通常要获得对所解决的问题域很清楚的专家的帮助。对于建模者所定义的类通常要有这样二个特点：一是使用来自问题域的概念，二是类的名字用该类实际代表的涵义命名。

         下面列出一些可以帮助建模者定义类的问题：

l  有没有一定要存储或分析的信息？如果存在需要存储，分析或处理的信息，那么该信息有可能就是一个类。这里讲的信息可以是概念（该概念总在系统中出现）或事件或事务（它发生在某一时刻）。

l  有没有外部系统？如果有，外部系统可以看作类，该类可以是本系统所包含的类，也可以是本系统与之交互的类。

l  有没有模板、类库、组件等？如果手头上有这些东西，它们通常应作为类。模板、类库、组件可以来自原来的工程、或别人赠送或从厂家购买的。

l  系统中有被控制的设备吗？凡是与系统相连的任何设备都要有对应的类。通过这些类控制设备。

l  有无需要表示的组织结构？在计算机系统中表示组织机构通常用类，特别是构建商务模型时用得更多。

l  系统中有哪些角色？这些角色也可以看成类。比如，用户、系统操作员、客户等。

依照上述几条可以帮助构建者找到需要定义的类。需要说明的是，定义类的基础是系统的需求规格说明，通过分析需求说明文档，从中找到需要定义的类。

4.2.2名字、属性和操作

         大家知道，类的图形表示为长方形，长方形又分成三个部分，分别用来表示类的名字、属性和操作，下面详细介绍这三个部分的具体表示方法和含义。

1、  名字

类的名字用黑体字书写在长方形最上面，给类命名时最好能够反映类所代表的问题域中的概念。比如，表示小汽车类产品，可以直接用“小汽车”作为类的名字。另外，类的名字含义要清楚准确，不能含糊不清。类通常表示为一个名词，既不带前缀，也不带后缀。

2、  属性

类的属性放在类名字的下方，用例描述该类的对象所具有的特征。在图4-2中，“小汽车”是类的名字，注册号、生产日期、时速、方向是“小汽车”的属性。描述类的特征的属性可能很多，在系统构建时，我们只抽取哪些系统中需要使用的特征作为类的属性。

换句话说，只关心那些“有用”的特征，通过这些特征就可以识别该类的对象。从系统处理的角度讲，可能被改变值的特征，才作为类的属性。

           正如变量有类型一样，属性也是有类型的，属性的类型反映属性的种类。比如，属性的类型可以是整形、实型、布尔型、枚举型等基本类型。除了基本类型外，属性的类型可以是程序设计语言能够提供的任何一种类型，包括类的类型。

 

属性有不同的可见性（visibility）。利用可见性可以控制外部事物对类中属性的操作方式。属性的可见性通常分为：共有的（public）、私有的（private）和保护的（protected）。共有属性能够被系统中其他任何操作查看和使用，当然也可以被修改；私有属性仅在类内部可见，只有类内部的操作才能存取该属性，并且该属性也不能被其子类使用；保护属性供类中的操作存取，并且该属性也能被其子类使用。

           属性的可见性可以不限于上述的三种，某些具体的程序设计语言还可以定义其他的可见性类型，但是，在表示类图时，必须含有公有类型和私有类型。在类图中，公有类型表示为加号（+），私有类型表示为减号（-），它们标识在属性名称的左侧。如果属性名称旁没有标识任何符号，表示该属性的可见性尚未定义。注意，这里不存在缺省的可见性。类属性的缺省值可以表示在类图中。这样，当创建该类的对象时，该对象的属性值便自动被赋以图示的缺省值。

 

3、  操作

属性仅仅表示了需求处理的数据，对数据的具体处理方法的描述则放在操作部分。存取或改变属性值或执行某个动作都是操作，操作说明了该类能做些什么工作。操作通常又称为函数，它是类的一个组成部分，只能作用于该类的对象上。从这一点也可以看出，类将数据和对数据进行处理的函数封装起来，形成一个完整的整体，这种机制非常符合问题本身的特性。

           在类图中，操作部分位于长方形的最底部，一个类可以有多种操作，每种操作由操作名、参数表、返回值类型等几部分构成，标识语法格式为：可见性 操作名（参数表）；返回值类型{性质串}

其中可见性和操作是不可缺少的。操作名、参数表和返回值类型合在一起称为操作的标记（signature），操作标记描述了使用该操作的方式，操作标记必须是唯一的。注意：操作只能应用于该类的对象，比如，drive()只能作用于小汽车类的对象。

 

操作的可见性也分为公有（用加号表示）和私有（用减号表示）两种，其含义等同于属性的公有和私有可见性。

           参数表由多个参数（用逗号分开）构成，参数的语法格式为：

参数名：参数类型名=缺省值

其中缺省值的含义是，如果调用该操作时没有为操作中的参数提供实在参数，那么系统就自动将参数定义式中的缺省值赋给该参数。

           其实，操作的描述方式有点像程序设计语言（比如C语言）的函数定义，所起的作用也差不多。因此，操作可以看做是类的一个接口，通过该接口实现内、外信息的交互。操作的具体实现称作方法，它与实现该操作的算法有关。若算法设计得好，可以减少操作的时空开销，满足求解问题的要求。除了算法以外，一个操作能否执行还与前提条件和收入参数有关。所谓前提条件是指操作可以执行的基础，比如，执行放大图形操作的前提条件是被放大的图形一定要存在，否则，放大图形的操作不能执行。操作执行完毕后，被操作对象的形态会受到影响，这种受影响的状况，称为后置条件。比如，执行放大图形操作的结果是原来的图形被放大了。由于图形被放大，随之而来的是表示图形位置的属性的改变，因此，执行操作时，对象属性状态的改变情况也要记录下来。综上所述，要完整的描述一个操作，必须包括：操作的标识（返回值、名字、参数表）、执行操作的前提条件、操作执行完毕后的后置条件、实现操作的算法和对象状态的改变情况。在类图中，关于操作的这些规格说明称为操作的性质，操作的性质不会直接显示在类图中，它可以用文字说明。可以使用CASE工具为操作设置超链功能，单击操作便可获得操作的性质。

           类也有类作用域操作，图示为带下划线的形式，如下图。引入类作用域操作的好处在于只有本类的对象才能使用该操作，一些通用的操作可以设计为类作用域操作，比如：产生对象和发现对象。需要注意的是，类作用域操作只能存取本类中的类作用域属性。

           有一种特别的类，叫做持久类（persistent class）。当产生对象的程序draw()运行结束时，所需的对象便生成了，同时生成的对象将自身存入数据库、文件或其他永久性的存储器中。通常该类还会有一个类作用域操作，用此操作完成对象的存储，通常这种操作表示为STORE()、LOAD()、CREATE()等。在类图中，如果某个类需要定义为持久的类，那么需要在类的名字旁边附加上{persistent}标志。

 

4.2.3基本类型的使用

           基本类型指的是像整型、实型、枚举型这样的简单类型，它不是类。基本类型常被用来表示返回值的类型、参数的类型和属性的类型。UML中没有预定义的基本类型，当用户在case工具中画UML中定义的各种图时，可以将case工具的工作环境配置为某一具体的编程语言，这样该语言本身所提供的基本类型就可以在case工具中使用了、如果不需要以某种具体语言为实现背景，或者不清楚用哪种语言，那么可以使用最简单的最常用的整型、字符串和浮点类型等，这些常用类型可以在UML语言中定义。以类图方式定义的类也可以用于定义属性类型、返回值类型和参数类型等。

4.3关系

前文已述，类图由类和它们之间的关系组成。类与类之间通常有关联、通用化（继承）、依赖和精化四种关系。

4.3.1关联关系

         关联用于描述类与类之间的连接。由于对象是类的实例，因此，类与类之间的关联也就是其对象之间的关联。类与类之间有多种连接方式，每种连接的含义各不相同（语义上的连接），但外部表示形式相似，故统称关联。关联关系一般都是双向的，即关联的对象双方彼此都能与对方通信。反过来说，如果某两个类的对象之间存在可以互相通信的关系，或者说对象双方能够感知另一方，那么这两个类之间就存在关联关系。描述这种关系常用的字句是：“彼此知道”、“互相连接”等。对于构建复杂系统的模型来说，能够从需求分析中抽象出类和类与类之间的关系是很重要的。

         根据不同的含义，关联可分为普通关联、递归关联、限定关联、或关联、有序关联、三元关联和聚合等七种。

4.3.1.1普通关联

         普通关联是最常见的一种关联，只有类与类之间存在连接关系就可以用普通关联表示。

        

 

由于关联是双向的，可以在关联的一个方向上为关联起一个名字，而在另一个方向上起另一个名字（也可不起名字），名字通常紧挨着直线书写。为了避免混淆，在名字的前面或后面带一个表示关联方向的黑三角，黑三角的尖角指明这个关联只能用在尖角所指的类上。通过直观的图示就可以很清楚地表达这种关联，如上图表示：“某位作家在使用计算机”。就像给类起的名字应能代表问题域本身的含义一样，给关联起的名字最好使用能够反映类之间关系的动词。

         如果类与类之间的关联是单向的，则称为导航关联。导航关联采用实线箭头连接两个类。只有箭头所指的方向上才有这种关联关系。其实，双向的普通关联可以看做导航关联的特例，只不过省略了表示两个关联方向的箭头罢了。

 

         除了上述的图示方式外，还可以在类图中图示关联中的数量关系---重数，比如，一个人可以拥有零辆车或多辆车。表示数量关系时，用重数说明数量或数量范围，也就是说，有多少个对象能被连接起来。

 

         如果图中没有明确标识关联的重数，那就意味着是1.类图中，重数标识在表示关联关系的某一个方向上直线的末端。图4-15中关联的含义是：人可以拥有零到多辆车，车可以被1至多人拥有。

 

         类图简单直观的描述了类、对象及它们之间的关系。通过类图可以反映出哪些对象之间有关系，系统是如何运作的。

         对于一个复杂的系统来说，特别是信息系统、商务系统，应当利用构建的模型，模拟跟踪系统的工作状况，通过跟踪所创造的模型，验证系统的正确性和有效性，以便尽早发现系统模型的不足之处，及时更改、定型，加快后期开发工作。如果没进行跟踪验证，而在实际阶段发现问题，导致重新建模的话，将会增加系统开发成本和开发周期。所以，建模者在建模初期就要将问题考虑全面，使所建模型对各种情况都要有相应的处理结果，满足所解问题的需求。

4.3.1.2对象图

         类图表示类与类之间的关系，对象图则表示在某一时刻这些类的具体实例和这些实例之间的具体连接关系。由于对象是类的实例，所以，UML对象图中的概念与类图中的概念完全一致，对象图可以看作类图的示例，帮助人们理解一个 比较复杂的类图，对象图也可用于显示类图中的对象在某一点的连接关系。

         对象的图示方式和类图示方式几乎是一样的。主要差别在于对象的名字下面要加下划线。对象名有下来三种表示格式：

 

 

4.3.1.3递归关联

         如果一个类与它本身有关联关联，那么这种关联称为递归关联（recursive association）。递归关联指的是同类的对象之间语义上的连接。比如，网络上的结点可以看做一个类，那么用类图表示的网络结构如图4-20的对象图，则一种可能的连接方式如图4-21所示。图4-21才真正反映出对象之间的连接关系，而从其类图所看到的，只是类连接到该类本身。

 

4.3.1.4关联中的角色

         任何关联关系都涉及到与此关联有关的角色，也就是与此关联相连的类中的对象所扮演的角色。比如，图4-22（a）所示类图中的人和车，在人“驾驶”这个关联联系中，人扮演的是司机角色，车的所有权可由汽车公司扮演。又如图4-22（b）中的“结婚”递归关联关系，一个人与另一个人结婚，必然一个扮演的是丈夫角色，另一个是妻子。如果一个人没有结婚，那么这个人不能做妻子或丈夫，因此，对这个人来说不能应用“结婚”关联关系。

         关联中的角色通常用字符串命名。在类图中，把角色的名字放置在与此角色有关的关联关系（直线）的末端，并且紧挨着使用该角色的类。角色名是关联的一个组成部分，建模者可根据需要选用。引入角色的好处是：指明了类和类的对象之间的联系（context）。注意，角色名不是类的组成部分，一个类可以在不同的关联中扮演不同的角色。

 

4.3.1.5限定关联

         限定关联用于一对多或多对多的关联关系中。在限定关联中，使用限定词将关联中多的那一端的具体对象分成对象集。限定词可以理解为一种关键词，用关键词把所有的对象分开。利用限定关联可以把模型中的重数从一对多变成一对一。类图中，限定词放置在关联关系末端的一个小方框内，紧挨着开始导航的类。

 

4.3.1.6 或关联

         图4-25是保险业务的类图，从图中可以看出，人可以与保险公司建立保险合同，一般公司也可以与保险公司建立保险合同，显然人持有的合同与一般公司持有的合同应该不同，也就是说，人与保险合同的关联关系不能同公司于保险合同的关联关系同时发生。为了解决这类问题，人们引入了“或关联”。所谓或关联就是对二个或更多个关联附加的约束条件，使类中的对象一次只能应用于一个关联关系中。或关联的图示方法是，具有“或关系”的关联之间用虚线连接起来，虚线上方标注规格说明{或}，如图4-26所示。

 

4.3.1.7 有序关联

         对象与对象之间的连接可以具有一定的次序，就像把窗口安排在屏幕上一样。一般情况下，对象之间的关联都是无序的，如果要明确表示关联中的次序关系，一定要将规格说明{排序}放在表示关联的直线旁，且紧挨着对象被排序的类。

 

4.3.1.8 关联类

         与一个关联关系相连的类，称作关联类。关联类并不位于表示关联关系的直线两端，二而是对应一个实际的关联，用关联类表示该实际关联的一些附加信息。关联中的每个连接与关联类中对象相联系。

 

4.3.1.9 三元关联

         类与类之间的关联关系，不仅限于两个类之间，多个类之间也可以有关联关系。如果三个类之间有关联关系，则称之为三元关联。三元关联图示为一个大的菱形，菱形的角与关联的类之间用直线相连（也可以用虚线连接）。注意，三元关联中可以出现角色和重数，但是不能出现限定词和聚合。

 

4.3.1.10 聚合（aggregation）

         聚合是关联的特例。如果类与类之间的关系具有“整体与部分”的特点，则把这样的关联称为聚合。例如，汽车由四个轮子、发动机、地盘等构成，则表示汽车的类与表示轮子的类、发动机的类、地盘的类之间的关系就具有“整体与部分”的特点，因此，这是一个聚合关系。识别聚合关系的常用方式是寻找“由。。构成”、“包含”、“是。。的一部分”等字句，这些字句很好地反映了相关类之间的“整体—一部分”关系。

         聚合的图示方式为，在表示关联关系的直线末端加一个空心的小菱形，空心菱形紧挨着具有整体性质的类，如图4-30所示，聚合关系中可以出现重数、角色（仅用于表示部分的类）和限定词，也可以给聚合关系命名。

 

         除去上述一般聚合外，聚合还有两种特殊的聚合方式，共享聚合和复合聚合。

         如果聚合关系中的处于部分方向的对象同时参与了多个处于整体方对象的构成，则该聚合称为共享聚合。比如，一个球队（整体方）由多个球员（部分方）组成，但是一个球员还可能加入了多个球队，球队和球员之间的这种关系就是共享聚合。共享聚合关系可以通过聚合重数反映 处理，如果作为整体方的类的重数不是1，那么该聚合就是共享聚合。

 

         如果构成整理类的部分类，完全隶属于整体类，则这样的聚合称为复合聚合。换句话说，如果没有整体类则部分类也没有存在价值，部分类的存在是因为有整体类的存在。比如，窗口由文本框、列表框、按钮和菜单组成。整体方的重数必须是零或1，部分方的重数可取任意范围值。复合聚合是一个树状结构的关联关系。复合聚合图示为一个带实心菱形的直线，实心菱形紧挨着整体方的类。

 

 

4.3.2 通用化

         一个类（通用元素）的所有信息（属性或操作）能被另一个类（具体元素）继承，继承某个类的类中不仅可以有属于自己的信息，而且还拥有了被继承类的信息，这种机制就是通用化。

         通用化又称继承。UML中的通用化是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可附加一些其他信息。比如，小汽车是交通工具，如果定义了一个交通工具类表示关于交通工具的抽象信息（发动、行使等），那么这些信息（通用元素）可以包含在小汽车类（具体元素）中。引入通用化的好处在于由于把一般的公共信息从通用元素中继承得来，增强了系统的灵活性、易维护性和可扩充性。程序员只有定义新扩充或更改的信息就可以了，旧的信息完全不必修改（仍可以继续使用），大大缩短了维护系统的时间。

         通用化可以拥有类、用例等各种模型元素。注意，通用化针对类型，而不针对实例。比如，一个类继承另一个类，但一个对象不能继承另一个对象。

         通用化分为普通通用化和受限通用化。

4.3.2.1 普通通用化

         具有通用化关系的两个类之间，继承通用类所有信息的具体类，称为子类，被继承类称为父类。可以从父类中继承的信息有属性、操作和所有的关联关系。

         父类和子类的通用化关系图示为一个带空心三角形的直线。空心三角形紧挨着父类。

 

         类的继承关系可以是多层的。也就是说，一个子类本身还可以作另一类的父类，层层继承下去。

 

4.3.2.2 受限通用类

         给通用化关系附加一个约束条件，进一步说明该通用化关系的使用方法或扩充方法，这样的通用化关系成为受限通用化。预定义的约束有四种：多重、不相交、完全和不完全。

         图4-44图示了两种约束通用化的表示方法，（a）是多个子类共用一个箭头指向父类，约束用花括号括起来放在直线旁边，多个约束之间用逗号分隔。（b）中的继承关系是单独图示的，这种情况下，要另外附加一条虚线（穿越所有的继承关系）。

 

4.3.3 依赖和精化关系

         依赖关系描述的是两个模型元素（类、组合、用例等）之间的语义上的连接关系。其中，一个模型元素是独立的，另一个模型元素是非独立的（依赖的），它依赖于独立的模型元素，如果独立的模型元素发生改变，将会影响依赖该模型元素的模型元素。比如，某个类中使用另一个类的对象作为操作中的参数，则这两个类之间就具有依赖关系，类似的依赖关系还有一个类存取另一个类中的全局对象，以及一个类调用另一类中的类作用域操作。图示具有依赖关系的是两个模型元素时，用带箭头的虚线连接，箭头指向独立的类，箭头旁边还可以带一个版类（stereotype）标签，具体说明依赖的种类。

 

4.4约束和派生规则

         UML中的规则称为约束和派生。约束用于限制一个模型。我们已经讨论过的约束有或关联、有序关联和四种继承约束（多重、不想交、完全和不完全）。派生用于描述某种事物的产生规则。比如说，一个人的年龄可以由该人的生日和当前日期派生出来（两者之差）。一般说来，约束和派生能应用于任何模型元素，但最常用于属性、关联、继承、角色和时间。图示中的约束和派生都用花括号括起来放在模型元素的附近，或者用圆括号括起来，以笔记的方式与模型元素相连。

         关联关系可以被约束，也可以派生。如果一个关联是另一个关联的子集，则它们之间就会存在约束关联。如图4-49中的“领导”关联中的政治家是“组成”关联中成员的子集。派生关联由现有的关联关系衍生而来，图示时，派生关联的名称前加一条斜线，比如，4-50中的“VIP客户”关联就是派生来的。因为出租车公司和很多客户有租车合同，这里面有些人是很重要的，于是在公司和客户之间之间派生出关联关系。

 

 

         通用化关系只有约束，没有派生。对UML模型元素应用的约束和派生（规则），也可以用UML语言语法机制表示。表示规则的语法称为导航表达式，它构成说明一个具体规则的基本语句。根据需要，有时可以扩展导航表达式。

下面介绍五种常见语法的书写形式：

形式一： set.attribute

Set是一个表达式，代表一个对象或对象集，attribute是set所代表对象的一个属性名，它们之间用“.”号相连接。形式一的结果是属性的值，结果值可能是单值，也可能是多值，具体结果依赖于关联的重数。

形式二：set.role

其中set的含义同形式一，role代表关联关系中目的方角色名，它们之间用“.”相连。形式二的结果为一个或多个对象，对象的多少依赖于关联的重数。

形式三：set.~role

形式三与形式二的含义差不多，不同之处在于role代表关联关系中的起始方的角色名，role前面多加一个“~”符合，表示对关联关系的逆转。具体结果仍然是与关联的重数有关的对象或对象集。

形式四：set[布尔表达式]

Set是代表一个对象或多个对象表达式，布尔表达式用set中对象书写，并用方括号括起来。形式四的结果值是使布尔表达式为真的对象（是set的一个子集）。

形式五：set.[限定词的值]

Set是代码一个对象或多个对象的表达式，限定词指明一个限定set的限定关联，限定词代表限定关联中的限定属性值。

4.5接口

         接口通常被描述为抽象操作，也就是只用标识（返回值、操作名称、参数表）说明它的行为，而真正实现部分放在使用该接口的元素中。这样，应用该接口的不同元素就可以对接口采用不同的实现方法。在执行过程中，调用该接口的对象看到的仅仅是接口，而不管其他事情，比如，该接口是由哪个类实现的，怎么实现的，都有哪些类实现了该接口等。通俗的讲，接口的具体实现过程、方法，对调用该接口的对象是透明的。

         接口在类图中表示为一个带接口名称的小圆圈。接口与应用它的模型元素之间用一条直线相连（模型元素中包含了该接口的具体实现方法），它们之间是一对一的关联关系。调用该接口的类与接口之间用带箭头的虚线连接，它们之间是依赖关系。

         为了具体标识接口中的操作，接口也可以图示为带版类《接口》的类，如图4-52所示。类图中反映不出接口中的操作。

 

4.6 包

         包（package）是一种组合机制，把各种各样的模型元素通过内在的语义连在一起成为一个整体就叫做包。构成包的模型元素称为包的内容。包通常用于对模型的组织管理，因此有时又将包称为子系统（subsystem）。包用于自己的模型元素，包与包之间不能共用一个相同的模型元素。包的实例没有任何语义（含义）。仅在模型执行期间，包才有意义。

         包能够引用来自其他包的模型元素。当一个包从另一个包中引用模型元素时，这两个包之间就建立了关系。包与包之间允许建立的关系有依赖、精化和通用化。注意，只能在类型之间建立关系，而不是在实例之间建立，因为包的实例没有语义。

         包图示为类似书签卡片的形状，由二个长方形组成，小长方形（标签）位于大长方形的左上角。如果包的内容（比如类）没被图示出来，则包的名字可以写在大长方形内，否则包的名字写在小长方形内。

 

         包与聚合很相似，如果一个包是由模型元素构成的（拥有自己的内容），那么该包是复合聚合；反之，如果一个包从其他的包中引用模型元素，该包是共享聚合。

         和类一样，包也有可见性，利用可见性控制外部包对包中内容的存取方式。UML中对包定义了四种可见性：私有、保护、公有和实现。缺省的可见性为公有。公有可见性允许其他元素存取和使用包中的内容。私有可见性意味着包中的元素只能被拥有或引用该元素的包存取和使用。保护可见性除具有私有可见性的存取要求外，还允许有继承关系的包（一般的包和具体的包）中的具体包存取一般包中的元素。实现可见性与私有可见性很相似，但是有依赖关系的包之间，如果被引用（imported）的包定义为实现可见性，则不允许引用该包中的元素使用被引用包中的元素。换句话说，如果一个包有实现可见性，则不允许其他包引用该包（即无依赖关系）。实现可见性尚无特定的表示符号。

 

4.7 模板

         模板（templet）是一个尚未完全具体说明的类。模板中提供参数表，利用参数表像模板传递信息可最终形成用户需要的具体类。参数可以是类，也可以是整型、布尔型等基本类型。由于给定不同的参数便可确定不同的类，所以模板能够说明许多类，故又称模板是一个用参数表示的类，如图所示。图中array就是一个模板（用长方形表示），右上角的虚框表示一个参数表，参数表中的参数由参数名和参数类型构成，多个参数之间用逗号分隔。如果参数的类型时类，则可以省略该的类型说明

 

         模板可以是数组等各种类型。模板的实例时给定模板中参数值之后所得到的类的规格说明。如果模板是数组，那么它的实例可能是一组汽车、一组颜色等等。模板的实例图示为一个与类一样的矩形，但是类的名字中药反映出该类是哪个模板的实例，以及所给定的参数。比如，Array<Car,100>。也可以在类图中表示模板的实例与模板 之间的关系，它们的关系是精化关系，用版类《bind》表示，《bind》后面紧跟着模板的实在参数。