学步园

回页首

更详细的解释：http://www.cnitblog.com/Lily/archive/2006/02/23/6860.html

基础

在大多数的 UML 模型中这些类型包括：

• 类

• 接口

• 数据类型

• 组件

UML 为这些类型起了一个特别的名字：“分类器”。通常地，你可以把分类器当做类，但在技术上，分类器是更为普遍的术语，它还是引用上面的其它三种类型为好。

类名

类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。图 1 显示一个航线班机如何作为 UML 类建模。正如我们所能见到的，名字是Flight，我们可以在中间区域看到Flight类的3个属性：flightNumber，departureTime 和 flightDuration。在底部区域中我们可以看到Flight类有两个操作：delayFlight
和 getArrivalTime。

图 1: Flight类的类图

类属性列表

类的属性节（中部区域）在分隔线上列出每一个类的属性。属性节是可选择的，要是一用它，就包含类的列表显示的每个属性。该线用如下格式：

name : attribute type

flightNumber : Integer

继续我们的Flight类的例子，我们可以使用属性类型信息来描述类的属性，如表 1 所示。

表 1：具有关联类型的Flight类的属性名字

在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。

在类图上显示具有默认值的特定属性，有时是有用的（例如，在银行账户应用程序中，一个新的银行账户会以零为初始值）。UML 规范允许在属性列表节中，通过使用如下的记号作为默认值的标识：

name : attribute type = default value

举例来说：

balance : Dollars = 0

显示属性默认值是可选择的；图 2 显示一个银行账户类具有一个名为 balance的类型，它的默认值为0。

图 2：显示默认为0美元的balance属性值的银行账户类图。

类操作列表

类操作记录在类图长方形的第三个（最低的）区域中，它也是可选择的。和属性一样，类的操作以列表格式显示，每个操作在它自己线上。操作使用下列记号表现：

name(parameter list) : type of value returned

下面的表 2 中Flight类操作的映射。

表 2：从图 2 映射的Flight类的操作

图3显示，delayFlight 操作有一个Minutes类型的输入参数 -- numberOfMinutes。然而，delayFlight 操作没有返回值。 ¹ 当一个操作有参数时，参数被放在操作的括号内；每个参数都使用这样的格式：“参数名：参数类型”。

图 3：Flight类操作参数，包括可选择的“in”标识。

当文档化操作参数时，你可能使用一个可选择的指示器，以显示参数到操作的输入参数、或输出参数。这个可选择的指示器以“in”或“out”出现，如图3中的操作区域所示。一般来说，除非将使用一种早期的程序编程语言，如Fortran ，这些指示器可能会有所帮助，否则它们是不必要的。然而，在 C++和Java中，所有的参数是“in”参数，而且按照UML规范，既然“in”是参数的默认类型，大多数人将会遗漏输入/输出指示器。

继承

在面向对象的设计中一个非常重要的概念，继承，指的是一个类（子类）继承另外的一个类（超类）的同一功能，并增加它自己的新功能（一个非技术性的比喻，想象我继承了我母亲的一般的音乐能力，但是在我的家里，我是唯一一个玩电吉他的人）的能力。为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。考虑银行账户的类型：图 4 显示 CheckingAccount 和 SavingsAccount 类如何从 BankAccount 类继承而来。

图 4: 继承通过指向超类的一条闭合的，单箭头的实线表示。

在图 4 中，继承关系由每个超类的单独的线画出，这是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而，有一种称为树标记的备选方法可以画出继承关系。当存在两个或更多子类时，如图 4 中所示，除了继承线象树枝一样混在一起外，你可以使用树形记号。图 5 是重绘的与图 4 一样的继承，但是这次使用了树形记号。

图 5: 一个使用树形记号的继承实例

抽象类及操作 
细心的读者会注意到，在图 4 和 图5 中的图中,类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount 类使用withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。

然而，超类（父类）不一定要是抽象类。标准类作为超类是正常的。

• 组合与聚合关系（转）  

1.聚合与组合都是一种结合关系，组合（相互之间的依赖关系之意）只是额外具有整体-部分的意涵。

2.聚合关系中（相互独立的东西合作之意，如果一方撕毁协议，另一方还会生存），整件(wholeobject)不会拥有部件(partobject)的生命周期，所以整件删除时，部件不会被删除。再者，多个整件可以共享同一个部件。

3.组合关系中，整件拥有部件的生命周期，所以整件删除时，部件一定会跟着删除。而且，多个整件不可以同时间共享同一个部件。

至于，实务上倒底要采用聚合关系还是组合关系，不决定于真实，而是决定于企业规则。比方说，订单与细项之间的关系，通常采用组合关系，一旦订单被删掉时，底下的细项也会同时被删除。但是，这是比较常见的企业规则，试想，或许有些领域的交易是可以拆单的，订单被取消时，原先的细项可以被并入别的订单中，若是如此，就适合使用聚合关系了。

聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

我们用浅显的例子来说明聚合和组合的区别。“国破家亡”，国灭了，家自然也没有了，“国”和“家”显然也是组合关系。而相反的，计算机和它的外设之间就是聚合关系，因为它们之间的关系相对松散，计算机没了，外设还可以独立存在，还可以接在别的计算机上。在聚合关系中，部分可以独立于聚合而存在，部分的所有权也可以由几个聚合来共享，比如打印机就可以在办公室内被广大同事共用。

class A
{
public:
    A(B* b)
    {
        b_ = b;
    }

    void foo()
    {
        b_.SomeMethod();
    }
private:
    B* b_;

};

class A
{
public:
    A(B* b)  //这个函数的参数是B类里的b指针成员？还是指针 还是B类型的指针b
    {
        b_ = b; //这是什么意思？
    }

    void foo()
    {
        b_.SomeMethod(); //什么意思？
    }
private:
    B* b_; // 什么意思？

}; //请问聚合在哪里呀

class A {...} 
　class B { A* a; .....}
这样写总明白了吧。。

新手呀 不会呀
class A {...} 
class B { A* a; .....}  这俩是函数？ 都没有；
把程序带注释解释解释吧 
class A
{
public:
    A(B* b)  //这个函数的参数是B类里的b指针成员？还是指针 还是B类型的指针b
    {
        b_ = b; //这是什么意思？
    }

    void foo()
    {
        b_.SomeMethod(); //什么意思？
    }
private:
    B* b_; // 什么意思？

}; //请问聚合在哪里呀

》

B类中包含A类的指针，而如果A类的这个指针不存在，B类同样可以存在。
长的那段程序一样的道理，A类中包含了B类了的指针，b_=b是一个构造函数的赋值啊

关联 
当你系统建模时，特定的对象间将会彼此关联，而且这些关联本身需要被清晰地建模。有五种关联。在这一部分中，我将会讨论它们中的两个 -- 双向的关联和单向的关联，而且我将会在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: 多重值和它们的表示

单向关联 
在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。图 7 显示单向关联的透支财务报告的一个实例。

图 7: 单向关联一个实例：OverdrawnAccountsReport 类 BankAccount 类，而 BankAccount 类则对关联一无所知。

一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。在图 7 中的例子中，OverdrawnAccountsReport 知道 BankAccount 类，而且知道 BankAccount 类扮演“overdrawnAccounts”的角色。然而，和标准关联不同，BankAccount 类并不知道它与 OverdrawnAccountsReport
相关联。 ²

软件包 
不可避免，如果你正在为一个大的系统或大的业务领域建模，在你的模型中将会有许多不同的分类器。管理所有的类将是一件令人生畏的任务；所以，UML 提供一个称为 软件包的组织元素。软件包使建模者能够组织模型分类器到名字空间中，这有些象文件系统中的文件夹。把一个系统分为多个软件包使系统变成容易理解，尤其是在每个软件包都表现系统的一个特定部分时。 ³

在图中存在两种方法表示软件包。并没有规则要求使用哪种标记，除了用你个人的判断：哪种更便于阅读你画的类图。两种方法都是由一个较小的长方形（用于定位）嵌套在一个大的长方形中开始的，如图 8 所示。但是建模者必须决定包的成员如何表示，如下：

• 如果建模者决定在大长方形中显示软件包的成员，则所有的那些成员 ⁴ 需要被放置在长方形里面。另外，所有软件包的名字需要放在软件包的较小长方形之内（如图
  8 的显示）。

• 如果建模者决定在大的长方形之外显示软件包成员，则所有将会在图上显示的成员都需要被置于长方形之外。为了显示属于软件包的分类器属于，从每个分类器画一条线到里面有加号的圆周，这些圆周粘附在软件包之上（图9）。

图 8：在软件包的长方形内显示软件包成员的软件包元素例子

图 9：一个通过连接线表现软件包成员的软件包例子

了解基础重要性

在 UML 2 中，了解类图的基础更为重要。这是因为类图为所有的其他结构图提供基本的构建块。如组件或对象图（仅仅是举了些例子）。

回页首

超过基础

到此为止，我已经介绍了类图的基础，但是请继续往下读！在下面的部分中，我将会引导你到你会使用的类图的更重要的方面。这些包括UML 2 规范中的接口，其它的三种关联类型，可见性和其他补充。

接口 
在本文的前面，我建议你以类来考虑分类器。事实上，分类器是一个更为一般的概念，它包括数据类型和接口。

关于何时、以及如何高效地在系统结构图中使用数据类型和接口的完整讨论，不在本文的讨论范围之内。既然这样，我为什么要在这里提及数据类型和接口呢？你可能想在结构图上模仿这些分类器类型，在这个时候，使用正确的记号来表示，或者至少知道这些分类器类型是重要的。不正确地绘制这些分类器，很有可能将使你的结构图读者感到混乱，以后的系统将不能适应需求。

一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”，如图 10 所示。 ⁵

图 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 类的一个实例。