UML类图中的关联
UML类图中关联关系的导航方式和选择原则
UML类图中关联关系的导航方式和选择原则在软件开发中，UML类图是一种常用的建模工具，用于描述系统中的类和它们之间的关系。
其中，关联关系是类图中最基本的关系之一，用于表示类之间的连接。
关联关系可以分为双向关联和单向关联两种。
双向关联表示两个类之间的连接是相互的，而单向关联表示连接只是单向的。
在类图中，关联关系通常用带箭头的实线表示。
在使用关联关系时，我们需要考虑如何进行导航，即如何通过一个类的实例找到与之相关联的其他类的实例。
导航方式的选择取决于系统的需求和设计的目标。
一种常见的导航方式是使用关联类的引用。
在这种情况下，一个类的实例可以通过它与其他类的关联关系中的引用来访问相关联的实例。
例如，考虑一个订单管理系统，订单类和客户类之间存在关联关系。
通过订单类的一个引用，我们可以访问与该订单相关联的客户实例。
另一种导航方式是使用关联类的操作。
在这种情况下，一个类的实例可以通过调用关联类中定义的操作来访问相关联的实例。
例如，在一个电子商务系统中，订单类和商品类之间存在关联关系。
通过调用订单类中的一个操作，我们可以获取与该订单相关联的商品实例的信息。
在选择导航方式时，我们应该考虑以下几个原则：1. 一致性原则：在整个系统中，应该保持一致的导航方式。
如果在一个关联关系中使用了引用导航，那么在其他关联关系中也应该使用引用导航，以保持一致性和统一性。
2. 依赖性原则：导航方式应该尽量减少类之间的依赖性。
如果一个类的实例通过关联类的引用或操作来访问其他类的实例，那么这个类就会对关联类产生依赖。
为了降低类之间的耦合度，我们应该尽量避免过多的依赖关系。
3. 效率原则：导航方式应该尽量高效。
在设计关联关系时，我们应该考虑到系统的性能需求和实际运行环境，选择合适的导航方式以提高系统的响应速度和效率。
4. 安全性原则：导航方式应该保证系统的安全性。
在设计关联关系时，我们应该考虑到数据的隐私和安全性要求，选择适当的导航方式以保护系统中的敏感信息。
UML类图中关联关系的三种导航方式
UML类图中关联关系的三种导航方式在软件开发中，UML（统一建模语言）类图是一种常用的建模工具，用于描述系统中的类和它们之间的关系。
其中，关联关系是类图中最基本的一种关系，描述了类之间的连接。
在关联关系中，导航方式是指一个类如何访问与之相关联的其他类的对象。
在UML类图中，有三种常见的导航方式：单向导航、双向导航和自关联导航。
1. 单向导航单向导航是指一个类可以访问与之关联的其他类的对象，而被关联的类不能直接访问该类的对象。
这种导航方式常见于一对多的关联关系，其中一个类是主导类，而另一个类是从属类。
举个例子，考虑一个图书馆管理系统，图书馆类与图书类之间存在一种关联关系，一个图书馆可以管理多本图书。
在这种情况下，图书馆类可以通过关联关系访问图书类的对象，但是图书类无法直接访问图书馆类的对象。
2. 双向导航双向导航是指两个类可以互相访问对方的对象。
这种导航方式常见于一对一或多对多的关联关系，其中两个类都可以主动访问对方的对象。
继续以图书馆管理系统为例，考虑一个借阅记录类与读者类之间的关联关系。
一个借阅记录可以关联一个读者，同时一个读者也可以关联多个借阅记录。
在这种情况下，借阅记录类和读者类可以通过关联关系互相访问对方的对象。
双向导航可以提供更灵活的访问方式，但也需要注意双向关联的管理和维护。
在设计时，需要考虑到两个类之间的依赖关系和业务逻辑，避免出现循环依赖或不一致的情况。
3. 自关联导航自关联导航是指一个类与自身存在关联关系，可以访问自身的对象。
这种导航方式常见于树状结构或层级结构的模型。
举个例子，考虑一个组织机构管理系统，组织类与自身存在一种关联关系，一个组织可以包含多个子组织。
在这种情况下，组织类可以通过关联关系访问自身的对象，实现对组织结构的层级管理。
自关联导航可以用于描述递归结构或层级结构，提供了一种方便的方式来处理复杂的关系。
但是，在使用自关联导航时需要注意循环引用的问题，避免出现无限循环或死循环的情况。
UML类图的各符号含义
UML类图的各符号含义类图基本符号可拆分为虚线，箭头，实线，空心右三角，实心右三角，空心菱形和实心菱形。
由这些基本的图形进行组合构成了类图的基本符号。
这里要注意这几个符号的顺序，代表了类与类之间关系的耦合程度。
越向右耦合度越高。
其中虚线+箭头是表示即依赖的关系,实线+箭头表示关联的关系，虚线+空心右三角表示implements,实线+空心右三角表示的是泛化，即类的继承关系。
实线+空心菱形表示的是聚合的关系，实线+实心菱形则表示组合的关系。
另外一点是在看类图的时候要注意。
类图的思想其实也还没有脱离面向对象的思想，以某个类为中心，有些线是射入的而有些线是射出的。
射入的线表示的是这个类被哪些类所调用而射出的线则表示该类调用了哪些类，包括泛化，关联，依赖，聚合和组合四种关系。
这类似于离散数学中有关图部分的描述。
1. 类（Class）：使用三层矩形框表示。
第一层显示类的名称，如果是抽象类，则就用斜体显示。
第二层是字段和属性。
第三层是类的方法。
注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。
2. 接口：使用两层矩形框表示，与类图的区别主要是顶端有<<interface>>显示。
第一行是接口名称。
第二行是接口方法。
3. 继承类（extends）：用空心三角形+实线来表示。
4. 实现接口（implements）：用空心三角形+虚线来表示5. 关联（Association）：用实线箭头来表示，例如：燕子与气候6. 聚合（Aggregation）：用空心的菱形+实线箭头来表示聚合：表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分，例如：公司和员工组合（Composition）：用实心的菱形+实线箭头来表示组合：部分和整体的关系，并且生命周期是相同的。
例如：人与手7. 依赖（Dependency）：用虚线箭头来表示，例如：动物与氧气8. 基数：连线两端的数字表明这一端的类可以有几个实例，比如：一个鸟应该有两只翅膀。
UML类图关系泛化、继承、实现、依赖、关联、聚合、组合
继承、实现、依赖、关联、聚合、组合的联系与区别分别介绍这几种关系：继承实现指的是一个class 类实现interface 接口（可以是多个）的功能；实现是类与接口之间最常 见的关系；在Java 中此类关系通过关键字implements 明确标识，在设计时一般没有争 议性；依赖可以简单的理解，就是一个类A 使用到了另一个类B ，而这种使用关系是具有偶然性的、、 临时性的、非常弱的，但是B 类的变化会影响到A ；比如某人要过河，需要借用一条船， 此时人与船之间的关系就是依赖;表现在代码层面，为类B 作为参数被类A 在某个method 方法中使用；Inte rfare指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可 以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java 中此类关系通过关键字extends 明确标识，在设计时一般没有争议性；b lnterface_BQlass_A ClaSs_B关联他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这 种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而 且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A 中，也可能是关联类A 引用了一个类型为被关联类B 的全 局变量；聚合聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a 的关系，此 时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象， 也可以为多个整体对象共享；比如计算机与CPU 、公司与员工的关系等；表现在代码层面， 和关联关系是一致的，只能从语义级别来区分；组合组合也是关联关系的一种特例，他体现的是一种contains-a 的关系，这种关系比聚合更强， 也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生 命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联 关系是一致的，只能从语义级别来区分；对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向 关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区 分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别Cl3ss A 十 depend<Qlass.B classBJ ；:；；VoidClass_B的，所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的强弱程度依次为：组合＞聚合＞关联》依赖；聚合跟组合其实都属于关联只不过它们是两种特殊的关联因为本是同根生所以它们之间难 免会有相似之处下面让我们一起来看一下它们之间有何不同聚合与组合的概念相信不用我在此赘述大家就已经了解了下面直接上例子 程老师的《大话》里举大那个大雁的例子很贴切在此我就借用一下大雁喜欢热闹害怕孤独所 以它们一直过着群居的生活这样就有了雁群每一只大雁都有自己的雁群每个雁群都有好多 大雁大雁与雁群的这种关系就可以称之为聚合另外每只大雁都有两只翅膀大雁与雁翅的关 系就叫做组合有此可见聚合的关系明显没有组合紧密大雁不会因为它们的群主将雁群解散 而无法生存而雁翅就无法脱离大雁而单独生存一一组合关系的类具有相同的生命周期聚合关系图：构造函数不同雁群类:[csharp] view plaincopypublic class GooseGroup { public Goose goose; public GooseGroup(Goose goose) { this .goose = goose;} 10. }[csharp] view plaincopy1. 2. 3.4.5. 6.7. 8.9. 组合关系图:从从代码上看这两种关系的区别在于:1.public class GooseGroup2.{3.public Goose goose;4.5.6.public GooseGroup(Goose goose)7.{8.this.goose = goose;9.}10.}大雁类：[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}聚合关系的类里含有另一个类作为参数雁群类（GooseGroup）的构造函数中要用到大雁（Goose）作为参数把值传进来大雁类（Goose）可以脱离雁群类而独立存在组合关系的类里含有另一个类的实例化大雁类（Goose）在实例化之前一定要先实例化翅膀类（Wings）两个类紧密耦合在一起它们有相同的生命周期翅膀类(Wings)不可以脱离大雁类(Goose)而独立存在信息的封装性不同在聚合关系中，客户端可以同时了解雁群类和大雁类，因为他们都是独立的而在组合关系中，客户端只认识大雁类，根本就不知道翅膀类的存在，因为翅膀类被严密的封装在大雁类中。
UML图中类之间的关系_依赖,泛化,关联,聚合,组合,实现答辩
UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现1.2.3.4.5.6.类与类图1 类(Class封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。
2 在系统中，每个类具有一定的职责，职责指的是类所担任的任务，即类要完成什么样的功能，要承担什么样的义务。
一个类可以有多种职责，设计得好的类一般只有一种职责，在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。
3 类的属性即类的数据职责，类的操作即类的行为职责一、依赖关系(Dependence依赖关系（Dependence）：假设A类的变化引起了B 类的变化，则说名B类依赖于A类。
• 依赖关系(Dependency 是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。
大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。
• 在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。
[java] view plaincopyprint?1. public class Driver2. {3. public void drive(Car car4. {5. car.move(;6. }7. ……8. }9. public class Car10. {11. public void move(12. {13. ......14. }15. ……16. }{car.move(;}……}public class Car{public void move({......}……}依赖关系有如下三种情况：1、A类是B类中的（某中方法的）局部变量；2、A类是B类方法当中的一个参数；3、A类向B类发送消息，从而影响B类发生变化；GeneralizationGeneralization A是B和C的父类，B,C具有公共类（父类）A，说明A是B,C的一般化（概括，也称泛化）• 泛化关系(Generalization也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
UML类图及类与类之间的关系
UML类图及类与类之间的关系原⽂地址：类图⽤于描述系统中所包含的类以及它们之间的相互关系，帮助⼈们简化对系统的理解，它是系统分析和设计阶段的重要产物，也是系统编码和测试的重要模型依据。
1. 类类(Class)封装了数据和⾏为，是⾯向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。
在系统中，每个类都具有⼀定的职责，职责指的是类要完成什么样的功能，要承担什么样的义务。
⼀个类可以有多种职责，设计得好的类⼀般只有⼀种职责。
在定义类的时候，将类的职责分解成为类的属性和操作（即⽅法）。
类的属性即类的数据职责，类的操作即类的⾏为职责。
设计类是⾯向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。
在软件系统运⾏时，类将被实例化成对象(Object)，对象对应于某个具体的事物，是类的实例(Instance)。
类图(Class Diagram)使⽤出现在系统中的不同类来描述系统的静态结构，它⽤来描述不同的类以及它们之间的关系。
在系统分析与设计阶段，类通常可以分为三种，分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)，下⾯对这三种类加以简要说明：(1) 实体类：实体类对应系统需求中的每个实体，它们通常需要保存在永久存储体中，⼀般使⽤数据库表或⽂件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。
实体类来源于需求说明中的名词，如学⽣、商品等。
(2) 控制类：控制类⽤于体现应⽤程序的执⾏逻辑，提供相应的业务操作，将控制类抽象出来可以降低界⾯和数据库之间的耦合度。
控制类⼀般是由动宾结构的短语（动词+名词）转化来的名词，如增加商品对应有⼀个商品增加类，注册对应有⼀个⽤户注册类等(3) 边界类：边界类⽤于对外部⽤户与系统之间的交互对象进⾏抽象，主要包括界⾯类，如对话框、窗⼝、菜单等。
在⾯向对象分析和设计的初级阶段，通常⾸先识别出实体类，绘制初始类图，此时的类图也可称为领域模型，包括实体类及其它们之间的相互关系。
UML类图的箭头含义
UML类图的箭头含义1、关联：类之间的⼀种关系，如学⽣和⽼师。
代码中的表⽰：class Student{private Teacher mTeacher;}class Teacher{}2、双向关联：和关联⼀样，不过它是两个⽅向的，如学⽣和⽼师，⽼师和学⽣，双向关系。
代码中表⽰：class Student{private Teacher mTeacher;}clsass Teacher{private Student mStuent;}3、聚合：整体和部分的关系，is-a的关系，如⼿是⼈体的⼀分部。
通常是在构造函数的时候，通过new创建出来。
代码中的表⽰：class People{private Hand mHand;public People(){mHand = new Hand();}}4、组合：整体和部分的关系，has-a的关系，如汽车拥有引擎。
通常是通过构造函数或者setter赋值进去的。
代码中表⽰：class Car{private Engine mEngine;public void setEngine(Engine e){mEngine = e;}}5、依赖：是使⽤的关系，例如汽车使⽤喇叭来鸣笛，调⽤汽车鸣笛的⽅法时，就依赖于喇叭鸣笛⽅法。
代码中表⽰：class Car{private Horn mHorn;public void whistle(){mHorn.whistle();}6、继承：不解释。
7、实现接⼝：不解释。
⼩结：1、继承已实现的类图，箭头是三⾓形的，其他的是不闭合的箭头。
2、关联与聚合在代码中的表⽰，都类似。
主要是构建模型的时候，理解上的差别。
UML类图中的符号解释
UML类图中的符号解释在UML的定义中，描述类和对象之间的关系，包括以下⼏种⽅式：依赖（Dependency）、关联（Association）、聚合（Aggregation）、组合（Composition）、泛化（Generalization）和实现（Realization）。
现分别说明如下：1. 依赖（Dependency）在uml中，“依赖”表⽰为带箭头的虚线，箭头指向被依赖的元素。
是类与类之间的连接，表⽰为⼀个类依赖于另⼀个类的定义，其中⼀个类的变化将影响另⼀个类。
依赖总是单向的，不应该存在双向依赖，这⼀点要特别注意。
更具体的说，依赖可以理解为：⼀个类（A）对不在其实例作⽤域内的另⼀个类或对象（B）的任何类型的引⽤。
⼤致包含以下⼏种情况：（1）局部变量；（2）⽅法的参数；（3）静态⽅法的调⽤；下⾯是依赖关系的uml⽰意图：2. 关联（Association）在uml中，关联表⽰为带箭头的实线。
关联可以是单向的，也可以是双向的。
如果是双向关联，则可以表⽰为双向箭头，或者没有箭头。
⼀般来说，系统设计应表现为单向关联，这样利于维护。
⼀个关联可以附加“多重性”的修饰符，表⽰两个类之间的数量关系。
关联可以理解为：⼀个类（A）持有另⼀个类或对象（B）。
具体表现为：（1）成员变量下⾯是关联关系的uml⽰例图：上⾯的关联表⽰，⼀个Employee持有(has)0个或多个TimeCard。
3. 聚合（Aggregation）在uml中，聚合关系表⽰为空⼼的菱形箭头线。
聚合关系是关联关系的⼀种，表⽰⼀种“强”关联关系。
对⽐与关联关系，两个类是处于同⼀个层次的。
⽽聚合关系，两个类处于不同的层次，强调了⼀个整体/局部的关系。
例如⼀辆汽车有⼀个引擎，4个轮胎。
在聚合关系中，体现了⼀种“弱拥有”的概念。
也就是说，对象A拥有对象B，但B并不是A的组成部分。
更具体的表现为，如果A由B聚合⽽成，则A包含B的全局对象，但B对象可以不在A对象创建时创建。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UML类图中的关联、聚合和组合李云Email:***********************Blog: 摘要本文介绍了UML关联的三种形式，此外，通过给出例子和相应的程序源代码帮助读者加深理解。
关键词UML 关联聚合组合缩略语UML Unifed Modeling Language 统一建模语言参考资料《OMG UML Superstructure version 2.2》类图中的关联关联1 类图中的关联（association，请参见Superstructure的7.3.3节）表示两个或多个类实例之间所存在的一种语义关系（sematic relationship）。
一个关联至少有两个用属性（property，请参见Superstructure 的7.3.44节）表达的终端（end）。
一个关联关系表明了多个所关联类实例（instance）之间的连接（link），也就是说关联是连接的集合。
一个连接是一个包含两个关联终端的值的元组，每一个关联终端的值表示一个末端类型的实例。
图1中，连接类Car和类Window的直线就表示一个关联关系，这个关联关系只有一个连接，因为只有两个类。
连接的两个末端分别是car_和windows_，car_是终端类Car 的实例（名），而windows_是终端类型Window的实例（名）。
在1.3节讨论关联的元数时，我们会进一步讨论连接与关联的关系。
一个关联可以包含多个终端（或说多个类），且关联终端可以是相同的类型（或相同的类）。
图 1关联在我们的语言中的表现形式是什么样子的呢？下面先看看用Visual Paradigm for UML生成图1中的C++代码是怎么样的，在Visual Paradigm for UML中选择相应的C++代码生成菜单，如图2所示。
图 2此时，将出现如图3所示的对话框，选择所需生成代码的元素和被生成代码的存放路径后，点击“Generate”按钮。
之后，在相应的目录中将生成四个文件，分别是Car.h、Car.cpp、Window.h 和Window.cpp。
图 3为了看一看所生成的代码中关联是如何表达的，我们需要查看一下Car.h和Window.h。
其代码如图4所示。
从图4中可以看出关联关系在类中表现为一个成员变量或说是属性。
Car.h00001: #include <string>00002: #include <vector>00003: #include <exception>00004: using namespace std;00005:00006: #ifndef __Car_h__00007: #define __Car_h__00008:00009: // #include "Window.h"00010:00011: class Window;00012: class Car;00013:00014: class Car00015: {00016: private: Window* windows_;00017: };00018:00019: #endifWindow.h00001: #include <string>00002: #include <vector>00003: #include <exception>00004: using namespace std;00005:00006: #ifndef __Window_h__00007: #define __Window_h__00008:00009: // #include "Car.h"00010:00011: class Car;00012: class Window;00013:00014: class Window00015: {00016: private: Car* car_;00017: };0001800019: #endif图 41.1 关联的可导航性可导航性（navigability）表示一个关联中连接的一端在运行时是否能被另一端有效的存取。
或者通俗的说可导航性的意思就是一个类能否通过所关联的类实例来调用类的方法。
对于图1，如果没有指明可导航性，则默认是双向都可导航的，这也是为什么生成的代码会互相拥有一个对方类型的指针变量的原因。
对于图4，从导航性角度来说，由于类Car和类Window之间的关系是相互可导航的，所以类Car可以通过windows_变量调用类Window的方法（或说是函数）。
反之，类Window 也可以通过car_变量来调用类Car的方法。
回到图1中的类图，我们看一看是不是有些东西可以更加的精确。
比如，车（用类Car表示）可能需要调用窗户（用类Window表示）的成员函数以实现窗户的开关，但窗户却不需要调用车的任何函数去实现特定的功能，从UML角度来说，从类Car到类Window是可导航的，但从类Window 不需要导航到类Car。
为此，我们将图1修订成图5。
在1.2节讨论关联的多重性时，我们看一看一个不可导航的关联所生成的代码与可导航的关联有什么不同。
图 51.2 关联的多重性前面说到关联的终端是类的实例，但实例的个数可能是需要指定的，即可以根据应用的需要进行指定。
比如，通常情况下，一辆车有四个窗户，即窗户可以有四个实例；而一个窗户只能是属于一辆车。
这在UML中如何在关联关系上进行表达呢？在UML中对于关联，我们可以用多重性（multiplicity）来限定一个末端（或属性）的数量。
多重性是采用如下的格式来表示的：<lower-bound> ‘..’ <upper-bound>其中，<lower-bound>和<upper-bound>都是一个数字，分别表示实例个数的下限和上限。
此外，“*”表示任意多个，还有就是当上限和下限值相同时，即必须是一个固定值，我们可以采用简写形式。
比如，对于“1..1”我们可以简写成“1”，对于“*..*”我们可以简写成“*”。
加入多重性后的图如图6所示，在后面谈到聚合和组合时，我们会使该图更加的精确。
图6所生成的C++代码列出于图7中。
图 6Car.h00001: #include <string>00002: #include <vector>00003: #include <exception>00004: using namespace std;00005:00006: #ifndef __Car_h__00007: #define __Car_h__00008:00009: #include "Window.h"00010:00011: class Window;00012: class Car;00013:00014: class Car00015: {00016: private: std::vector<Window*> windows_;00017: };00018:00019: #endifWindow.h00001: #include <string>00002: #include <vector>00003: #include <exception>00004: using namespace std;00005:00006: #ifndef __Window_h__00007: #define __Window_h__00008:00009: class Window;00010:00011: class Window00012: {00013: };00014:00015: #endif图7图7与图4代码的区别有两处：由于类Window到类Car不具导航性，因此，在类Window中不再有成员变量car_。
由于在图6中我们增加了多重性，因此，图7中类Car的变量windows_从类型Window*变成了std::vector<Window*>，即从一个指针变成了一个标量。
在Visual Paradigm for UML 中我们可以设置对于多重性的实现是采用STL（Standard Template Library）中的vector 或还是C中的数组。
回到图3你可以看出对于“Association Implementation”我们选择的是vector。
1.3 关联的元数关联中类的个数表示关联的元数（N-ary），比如图1中所示的关联只有两个类，因此我们说它是二元关联（binary association）。
图8是从UML规范中提取出来的一个包含三元关联（ternary association）的类图。
图 8与二元关联所不同的是，三元及以上关联需采用一个菱形来连接所有的关联类。
前面我们谈到了关联与连接的关系，对于图 8中的三元关联，其中存在三个连接，即每二个关联类组成一个连接。
我们说这一个三元关联是由三个连接组成的。
此外，图 8中还存在一个二元关联，而且这一二元关联边上还有一个实心的小三角形。
这一小三角形在图中的作用是用于指示关联关系的阅读顺序。
比如，对于图中的二元关联，我们应当这么读“Player 在year_年参加过比赛”（对应的英文是：Player PlayedInYear year_）。
1.4 关联的可见性关联的可见性（visibility ，请参见Superstructure 的7.3.55节）是指一个类所拥有的关联对于这一类的外部是否可见。
可见性分为私有（private ）、保护（protected ）、包（package ）和公共（public ）四种。
各种可见性在UML 中的表示方法如下：“+”表示public ； “-”表示private ； “#”表示protected ； “~”表示package ； 从C++的角度来看，我们对于private 、protected 和public 都已非常熟悉，至于package ，它可以被理解为命名空间（namespace ）。
采用Visual Paradigm for UML 我们可以表示出关联的可见性。
可见性被放在关联终端的属性名之前，在图 1中加入关联的可见性后就变成了图 9。
在图9中你可以看到我们将两个关联末端的可见性都设置成了private ，也就是说，windows_对于类Car 的外部是不可见的，而car_对于类Window 的外部也是不可见的。
图 91.5 关联的属性字符串属性字符串（property string ）是采用花括号将其括起来，这些属性字符串可以应用于关联的终端。