UML中各图形或图标表⽰的意思
类
类 的 UML 表⽰是⼀个长⽅形，垂直地分为三个区，如图 1 所⽰。顶部区域显⽰类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是 可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。图 1 显⽰⼀个航线班机如何作为 UML 类建模。正如我们所能见到的，名字是 Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime 和 flightDuration。在底部区域中我们可以看到Flight类有两个操作：delayFlight 和 getArrivalTime。
图 1: Flight类的类图
继承
在 ⾯向对象的设计中⼀个⾮常重要的概念，继承，指的是⼀个类（⼦类）继承另外的⼀个类（超类）的同⼀功能，并增加它⾃⼰的新功能（⼀个⾮技术性的⽐喻，想象 我继承了我母亲的⼀般的⾳乐能⼒，但是在我的家⾥，我是唯⼀⼀个玩电吉他的⼈）的能⼒。为了在⼀个类图上建模继承，从⼦类（要继承⾏为的类）拉出⼀条闭合 的，单键头（或三⾓形）的实线指向超类。考虑银⾏账户的类型：图 4 显⽰CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承⽽来。
图 4: 继承通过指向超类的⼀条闭合的，单箭头的实线表⽰。
在 图 4 中，继承关系由每个超类的单独的线画出，这是在IBM Rational Ro和IBM Rational XDE中使⽤的⽅法。然⽽，有⼀种称为 树标记的备选⽅法可以画出继承关系。当存在两个或更多⼦类时，如图 4 中所⽰，除了继承线象树枝⼀样混在⼀起外，你可以使⽤树形记号。图 5 是重绘的与图 4 ⼀样的继承，但是这次使⽤了树形记号。
图 5: ⼀个使⽤树形记号的继承实例
在 图 4 中，继承关系由每个超类的单独的线画出，这是在IBM Rational Ro和IBM Rational XDE中使⽤的⽅法。然⽽，有⼀种称为 树标记的备选⽅法可以画出继承关系。当存在两个或更多⼦类时，如图 4 中所⽰，除了继承线象树枝⼀样混在⼀起外，你可以使⽤树形记号。图 5 是重绘的与图 4 ⼀样的继承，但是这次使⽤了树形记号。
图 5: ⼀个使⽤树形记号的继承实例
抽象类及操作
细 ⼼的读者会注意到，在图 4 和 图5 中的图中，类名BankAccount和withdrawal操作使⽤斜体。这表⽰，BankAccount 类是⼀个抽象类，⽽withdrawal⽅法是抽象的操作。换句话说，BankAccount 类使
龙凤仕女图⽤withdrawal规定抽象操作，并且CheckingAccount 和SavingsAccount 两个⼦类都分别地执⾏它们各⾃版本的操作。
然⽽，超类（⽗类）不⼀定要是抽象类。标准类作为超类是正常的。卜的组词
关联
当 你系统建模时，特定的对象间将会彼此关联，⽽且这些关联本⾝需要被清晰地建模。有五种关联。在这⼀部分中，我将会讨论它们中的两个 -- 双向的关联和单向的关联，⽽且我将会在Beyond the basics部分讨论剩下的三种关联类型。请注意，关于何时该使⽤每种类型关联的详细讨论，不属于本⽂的范围。相反的，我将会把重点集中在每种关联的⽤ 途，并说明如何在类图上画出关联。
双向（标准）的关联
关联是两个类间的联接。关联总是被假定是双向的；这意味着，两个类彼此知道它们间的联系，除⾮你限定⼀些其它类型的关联。回顾⼀下Flight 的例⼦，图 6 显⽰了在Flight类和Plane类之间的⼀个标准类型的关联。
图 6：在⼀个Flight类和Plane类之间的双向关联的实例
⼀ 个双向关联⽤两个类间的实线表⽰。在线的任⼀端，你放置⼀个⾓⾊名和多重值。图 6 显⽰Flight与⼀个特定的Plane相关联，⽽且Flight类知道这个关联。因为⾓⾊名以Plane类表⽰，所以Plane承担关联中的 “assignedPlane”⾓⾊。紧接于Plane类后⾯的多重值描述0...1表⽰，当⼀个Flight实体存在时，可以有⼀个或没有Plane与 之关联（也就是，Plane可能还没有被分配）。图 6 也显⽰Plane知道它与Flight类的关联。在这个关联中，Flight承担“assignedFlights”⾓⾊；图 6 的图告诉我们，Plane实体可以不与flight关联（例如，它是⼀架全新的飞机）或与没有上限的flight（例如，⼀架已经服役5年的飞机）关联。
由于对那些在关联尾部可能出现的多重值描述感到疑惑，下⾯的表3列出了⼀些多重值及它们含义的例⼦。
表 3: 多重值和它们的表⽰
可能的多重值描述
表⽰含义
0..10个或1个
1只能1个
0..*0个或多个
*0个或多个
1..*1个或我个
3只能3个
用四字成语0..50到5个
5..155到15个
单向关联
在⼀个单向关联中，两个类是相关的，但是只有⼀个类知道这种联系的存在。图 7 显⽰单向关联的透⽀财务报告的⼀个实例。
图 7: 单向关联⼀个实例：OverdrawnAccountsReport 类 BankAccount 类，⽽ BankAccount 类则对关联。
⼀ 个单向的关联，表⽰为⼀条带有指向已知类的开放箭头（不关闭的箭头或三⾓形，⽤于标志继承）
的实线。如同标准关联，单向关联包括⼀个⾓⾊名和⼀个多重值描 述，但是与标准的双向关联不同的时，单向关联只包含已知类的⾓⾊名和多重值描述。在图 7 中的例⼦
中，OverdrawnAccountsReport 知道 BankAccount 类，⽽且知道 BankAccount 类扮演“overdrawnAccounts”的⾓⾊。然⽽，和标准关联不同，BankAccount 类并不知道它与 OverdrawnAccountsReport 相关联。2
软件包
不可避免，如果你正在为⼀个⼤的系统或⼤的业务领域建模，在你的模型中将会有许多不同的分类器。管理所有的类将是⼀件的任务；所以，UML 提供⼀个称为 软件包的组织元素。软件包使建模者能够组织模型分类器到名字空间中，这有些象⽂件系统中的⽂件夹。把⼀个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的⼀个特定部分时。3
在图中存在两种⽅法表⽰软件包。并没有规则要求使⽤哪种标记，除了⽤你个⼈的判断：哪种更便于阅读你画的类图。两种⽅法都是由⼀个较⼩的长⽅形（⽤于定位）嵌套在⼀个⼤的长⽅形中开始的，如图 8 所⽰。但是建模者必须决定包的成员如何表⽰，如下：
如果建模者决定在⼤长⽅形中显⽰软件包的成员，则所有的那些成员4 需要被放置在长⽅形⾥⾯。另外，所有软件包的名字需要放在软件包的较⼩长⽅形之内（如图 8 的显⽰）。
年会公司祝福语如果建模者决定在⼤的长⽅形之外显⽰软件包成员，则所有将会在图上显⽰的成员都需要被置于长⽅形之外。为了显⽰属于软件包的分类器属于，从每个分类器画⼀条线到⾥⾯有加号的圆周，这些圆周粘附在软件包之上（图9）。
图 8：在软件包的长⽅形内显⽰软件包成员的软件包元素例⼦
宝妈男
图 9：⼀个通过连接线表现软件包成员的软件包例⼦
接⼝
在本⽂的前⾯，我建议你以类来考虑分类器。事实上，分类器是⼀个更为⼀般的概念，它包括数据类型和接⼝。
关 于何时、以及如何⾼效地在系统结构图中使⽤数据类型和接⼝的完整讨论，不在本⽂的讨论范围之内。既然这样，我为什么要在这⾥提及数据类型和接⼝呢？你可能 想在结构图上模仿这些分类器类型，在这个时候，使⽤正确的记号来表⽰，或者⾄少知道这些分类器类型是重要的。不正确地绘制这些分类器，很有可能将使你的结 构图读者感到混乱，以后的系统将不能适应需求。
⼀个类和⼀个接⼝不同：⼀个类可以有它形态的真实实例，然⽽⼀个接⼝必须⾄少有⼀个类来实现它。在 UML 2 中，⼀个接⼝被认为是类建模元素的特殊化。因此，接⼝就象类那样绘制，但是长⽅形
的顶部区域也有⽂本“interface”，如图 10 所⽰5
图 10：Professor类和Student类实现Person接⼝的类图实例
在 图 10 中显⽰的图中，Professor和Student类都实现了Person的接⼝，但并不从它继承。我们知道这⼀点是由于下⾯两个原因：1) Person对象作为接⼝被定义 -- 它在对象的名字区域中有“interface”⽂本，⽽且我们看到由于Professor和Student对象根据画类对象的规则（在它们的名字区域中没 有额外的分类器⽂本）标⽰，所以它们是 类对象。 2) 我们知道继承在这⾥没有被显⽰，因为与带箭头的线是点线⽽不是实线。如图 10 所⽰，⼀条带有闭合的单向箭头的点 线意味着实现（或实施）；正如我们在图 4 中所见到的，⼀条带有闭合单向箭头的实线表⽰继承。
更多的关联
在上⾯，我讨论了双向关联和单向关联。现在，我将会介绍剩下的三种类型的关联。
关联类
蓝藻是什么在关联建模中，存在⼀些情况下，你需要包括其它类，因为它包含了关于关联的有价值的信息。对于这种情况，你会使⽤ 关联类 来绑定你的基本关联。关联类和⼀般类⼀样表⽰。不同的是，主类和关联类之间⽤⼀条相交的点线连接。图 11 显⽰⼀个航空⼯业实例的关联类。
图 11：增加关联类 MileageCredit
在 图 11 中显⽰的类图中，在Flight类和 FrequentFlyer 类之间的关联，产⽣了称为 MileageCredit的关联类。这意味当Flight类的⼀个实例关联到 FrequentFlyer 类的⼀个实例时，将会产⽣ MileageCredit 类的⼀个实例。
聚合
聚合是⼀种特别类型的关联，⽤于描述“总体到局部”的关系。在基本的聚合关系中， 部分类 的⽣命周期独⽴于 整体类 的⽣命周期。
古琴选购举 例来说，我们可以想象，车 是⼀个整体实体，⽽ 车轮 轮胎是整辆车的⼀部分。轮胎可以在安置到车时的前⼏个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独⽴地Car类实例⽽存在。然 ⽽，有些情况下， 部分 类的⽣命周期并 不 独⽴于 整体 类的⽣命周期 -- 这称为合成聚合。举例来说，考虑公司与部门的关系。 公司和部门 都建模成类，在公司存在之前，部门不能存在。这⾥Department类的实例依赖于Company类的实例⽽存在。
让我们探讨基本聚合和组合聚合。
基本聚合
有聚合关系的关联指出，某个类是另外某个类的⼀部分。在⼀个聚合关系中，⼦类实例可以⽐⽗类存在更长的时间。为了表现⼀个聚合关系，你画⼀条从⽗类到部分类的实线，并在⽗类的关联末端画⼀个未填充棱形。图 12 显⽰车和轮胎间的聚合关系的例⼦。
图 12: ⼀个聚合关联的例⼦
组合聚合
组合聚合关系是聚合关系的另⼀种形式，但是⼦类实例的⽣命周期依赖于⽗类实例的⽣命周期。在图13中，显⽰了Company类和Department类之间的组合关系，注意组合关系如聚合关系⼀样绘制，不过这次菱形是被填充的。
图 13: ⼀个组合关系的例⼦
在 图 13 中的关系建模中，⼀个Company类实例⾄少总有⼀个Department类实例。因为关系是组合关系，当Company实例被移除/销毁时，Department实例也将⾃动地被移除/销毁。组合聚合的另⼀个重要功能是部分类只能与⽗类的实例相关（举例来说，我们例⼦中的Company 类）。
反射关联
水浒传读书笔记摘抄好词好句现 在我们已经讨论了所有的关联类型。就如你可能注意到的，我们的所有例⼦已经显⽰了两个不同类之间的关系。然⽽，类也可以使⽤反射关联与它本⾝相关联。起 先，这可能没有意义，但是记住，类是抽象的。图 14 显⽰⼀个Employee类如何通过manager / manages⾓⾊与它本⾝相关。当⼀个类关联到它本⾝时，这并不意味着类的实例与它本⾝相关，⽽是类的⼀个实例与类的另⼀个实例相关。
14：⼀个反射关联关系的实例
图14：描绘的关系说明⼀个Employee实例可能是另外⼀个Employee实例的经理。然⽽，因为“manages”的关系⾓⾊有%200..*的多重性描述；⼀个雇员可能不受任何其他雇员管理。
