本文和大家重点讨论一下UML组件图的建立，让我们依照UML2规范一步步建立UML组件图，相信通过本文的介绍你对UML组件图的创建有一定的认识。
UML组件图基础
现在，在UML2中画一个组件很类似于在一个类图上画一个类。事实上，在UML2中，一个组件仅仅是类概念的一个特殊版本。这意味着适用于类分类器的符号规则也适用于组件分类器。（如果你已经读了并理解了我以前的关于大体上的结构图和类图细节的文章[http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/bell/index.shtml]，你就会很易理解UML组件图）。
在UML2中，一个组件被画成堆积着可选择小块的一个立着的长方形。UML2中，组件的一个高层次的抽象视图，可以用一个长方形建模，包括组件的名字和组件原型的文字和/或图标。组件原型的文本是“component”，而组件原型图标是在左边有两个凸出的小长方形的一个大长方形（UML1.4中组件的符号元素）。图2显示，组件可以用UML2规范中的三种不同方法表示。
当在图上画一个组件时，重要的是，你总要包括组件原型文本（在双重尖括号中的那个component，如图2所示）和/或图标。理由呢在UML中，没有任何原型分类器的一个长方形被解释为一个类组件。组件原型和/或图标用来区别作为组件元素的长方形。
为组件提供/要求接口建模
在图2中所画的Order组件表现了所有有效的符号元素；然而，一个典型的UML组件图包括更多的信息。一个组件元素可以在名字区下面附加额外的区。如前面所提到的，一个组件是提供一个或更多公共接口的独立单元。提供的接口代表了组件提供给它的用户/客户的服务的正式契约。图3显示了Order组件有第二个区，用来表示Order组件提供和要求的接口。2
图3：这里额外的区显示Order组件提供和要求的接口。
在图3中的Order组件例子中，组件提供了名为OrderEntry和AccountPayable的接口。此外，组件也要求另外一个组件提供Person接口。3
UML组件图中组件接口建模的其它方法
UML2也引入另外一种方法来显示组件提供并要求的接口。这个方法是建立一个里面有组件名的大长方形，并在长方形的外面放置在UML2规范中称为接口符号的东西。这第二种方法在图4中举例说明。
图4:一种可选择的方法（与图3相比）：使用接口符号显示组件提供/要求的接口
在这第二种方法中，在末端有一个完整的圆周的接口符号代表组件提供的接口--“棒棒糖”是这个接口分类器实现关系符号的速记法。在末端只有半个圆的接口（又称插座）符号代表组件要求的接口（在两种情况下，接口的名字被放置在接口符号本身的附近）。即使图4看起来与图3有很大的不同，但两个图都提供了相同的信息--例如，Order组件提供两个接口：OrderEntry和AccountPayable，而且Order组件要求Person接口。
组件关系的建模
当表现组件与其他的组件的关系时，棒棒糖和插座符号也必须包括一支依存箭头（如类图中所用的）。在有棒棒糖和插座的UML组件图上，注意，依存箭从强烈的（要求的）插座引出，并且它的箭头指向供应者的棒棒糖，如图5所示。
图5：显示Order系统组件如何依赖于其他组件的UML组件图
图5显示，Order系统组件依赖于客户资源库和库存系统组件。注意在图5中复制出的接口名CustomerLookup和ProductAccessor。在这个例子中，这看起来可能是不必要的重复，不过符号确实允许在每个依赖于实现差别的组件中有不同的接口（和不同的名字）（举例来说，一个组件提供一个较小的必需的接口子类）。
子系统
在UML2中，子系统分类器是组件分类器的一个特别版本。因为这一点，子系统符号元素象组件符号元素一样继承所有的组件符号集规则。唯一的差别是，一个子系统符号元素由subsystem关键字代替了component，如图6所示。
图6：子系统元素的一个例子
UML2规范在如何区别子系统与组件方面相当含糊。从建模的观点，规范并不认为组件与子系统有任何区别。与UML1.x相比较，这个UML2模型歧义是新的。但是有一个理由。在UML1.x中，一个子系统被认为是一个软件包，而且这个软件包符号正对许多UML实践者造成困惑；因此，UML2中把子系统作为特殊的组件，因为这是最多的UML1.x使用者了解它的方式。这一改变确实把模糊引入图中，但是这一模糊更多的是UML2规范中对抗错误的一个现实反射。
【编辑推荐】
