| 组件是一个类，它表示一个包含封装内容的系统的模块部分，并且其表示形式在其环境中是可替换的。
组件根据提供的接口和所需的接口(可能通过端口公开)定义其行为。
组件作为一种类型，其一致性由这些提供的和需要的接口定义(包括它们的静态语义和动态语义)。因此，只有当两个组件类型一致时，一个组件才能被另一个组件替代。
系统功能的较大部分可以通过将组件作为包含组件或组件组件的一部分重用，并将它们所需和提供的接口连接在一起来组装。
在整个开发生命周期中对组件进行建模，并将其依次细化为部署和运行时。一个组件可以由一个或多个工件表示。
在设计时定义了间接实例化组件，但在执行时不存在可寻址对象。组件及其端口的运行时行为由实现它的分类器或部件的运行时行为定义。几个标准的原型都采用了这个属性，例如：<<Specification>>, <<Focus>>, <<Subsystem>>.
符号(Notation)
组件显示为带有关键字<<component>>的分类器矩形。
WeatherServices组件
（可选） 可以在组件矩形的右上角显示类似于UML 1.4图标的组件图标。如果显示了图标符号，则可以省略关键字“ component”。
UserServices组件
一个组件可以由一个或多个工件来表示，反过来，该工件可以被部署到其执行环境中。部署规范可以定义参数化组件执行的值。
提供的接口（Provided Interface）
提供的接口既可以是
- 直接由组件本身实现
- 由分类器实现组件之一实现
- 由组件的公共端口提供。
天气服务组件提供（实现）
天气预报界面
所需接口（Required Interface）
所需的接口是
- 由组件本身的使用依赖性指定
- 由分类器实现组件之一的使用依赖性指定
- 组件的公共端口需要
用户服务组件需要IOrderServices接口
组件外观（External View of Component）
一个组件有一个外部视图或“黑盒”视图，通过从组件盒中伸出的界面符号来显示其公开可见的属性和操作。
可选地，诸如协议状态机之类的行为可以附加到接口、端口和组件本身，以通过明确操作调用序列中的动态约束来更精确地定义外部视图。其他行为也可以与接口或连接器相关联，以定义协作中参与者之间的“契约”(例如，在用例、活动或交互规范方面)。
或者，接口和/或单独的操作和属性可以在组件框的隔间中列出(为了可伸缩性，工具可以提供一种列出和缩写组件属性和行为的方式)。
用户服务组件的外部视图-它提供
IUserServices接口，并需要IOrderServices接口
为了显示组件接口的完整签名，这些接口还可以显示为典型的分类器矩形，可以展开这些矩形以显示操作和事件的详细信息
标准组件原型（Standard Component Stereotypes）
有几个标准的UML原型适用于组件：
标准UML组件原型
| 名称 |
说明 |
| <<BuildComponent>> |
为系统级开发活动定义的元素集合，例如编译和版本控制。 |
| <<Entity>>
|
表示业务概念的持久信息组件。
实体组件客户
|
| <<Implement>>
|
实现是一个组件定义，它本身并不打算有一个规范。相反，它是一个独立规范的实现，它依赖于该规范。
|
| <<Process>>
|
流程是基于事务的组件。
|
| <<Realization>>
|
实现是一个分类器，它指定了对象的域，也定义了这些对象的物理实现。
例如，由实现模式化的组件将只具有实现由单独的规范组件指定的行为的实现分类器。这不同于实现类，因为实现类是一个类的实现，它可以具有对系统设计者有用的特性，例如属性和方法。 |
| <<Service>>
|
服务是一个无状态的功能组件。
服务组件WeatherServices
|
| <<Specification>>
|
规范是一个分类器，它指定对象的一个域，而不定义这些对象的物理实现。
例如，由<<Specification>>构造型的组件将只提供所需的接口，而不打算将任何可实现的分类器作为其定义的一部分。这与“type”不同，因为“type”可以具有对分析建模系统有用的属性和方法等特性。
“规范”和“实现”用于对具有不同规范和实现定义的组件建模，其中一个规范可能具有多个实现。
|
| <<Subsystem>>
|
子系统是代表大系统分层分解单元的组件，用于对大规模组件建模。子系统的定义可能在不同的领域和软件方法之间有所不同。预计域和方法概要文件将专门化这个元素。
子系统通常是间接实例化的。子系统可以有规范和实现元素。
|
历史（History）
在UML 2.0中引入了组件符号作为带有组件关键字的分类器矩形。
在以前版本的UML 1.x组件符号中，组件是一个矩形，有两个小矩形从其侧面突出。出于向后兼容的原因，这个符号仍然可以在UML 2.5中使用。
在UML 1.4.2中，原型<<entity>>表示一个被动类，即其对象不单独启动交互的类。“实体”成为UML 2.0中的一个持久信息组件。
原型<<process>>指定了一个分类器，表示UML 1.4.2中的一个重要控制流。在UML2.0中，<<Process>>成为一个基于事务的组件。
在UML 1.4.2中，“子系统”是一种特殊的包，用于表示物理系统中的行为单元，从而表示模型中的行为单元，并用作其包含的模型元素行为的规范单元。在UML2.0中，<<Subsystem>>成为表示大型系统层次分解单元的组件原型。
UML 2.0还引入了标准组件原型构建<<BuildComponent>>、<<Implement>>和<<Service>>。
例子（Examples）
在线购物组件图
一个用于在线购物的UML2.5组件图的例子。该图显示了三个相关子系统（WebStore、Warehouses和Accounting）的内部结构的“白盒”视图。在UML中，<<Subsystem>>是大型组件的标准组件原型，通常包含一些小型组件。
具有三个相关子系统的在线购物UML组件图示例-WebStore，Warehouse和Accounting。
WebStore 子系统包含三个与在线购物相关的组件：搜索引擎、购物车和身份验证。搜索引擎组件允许通过公开提供的界面产品搜索来搜索或浏览项目，并使用由库存组件提供的必需界面搜索库存。购物车组件在结账时使用Orders组件提供的管理订单接口。身份验证组件允许客户创建帐户、登录或注销，并将客户绑定到某个帐户。
Sentinel HASP许可组件
UML组件图的一个示例，其中提供了一些使用SafeNet Sentinel HASP软件授权安全解决方案和授权API的已提供和已实现组件的简化视图。
在图的顶部，我们使用Sentinel HASP-License Status.Net应用程序和许可服务Java组件实现了一些软件。许可证状态应用程序旨在显示许可证状态，并由License_Status.exe项目显示（实现）。许可服务Java组件实现了许可服务接口，可以被其他Java应用程序或服务使用。
许可证状态应用程序通过许可证服务接口使用许可证服务网络组件，该接口由该组件实现。许可证服务网络组件使用HASP。由HASP提供的。Net运行时组件，它是哨兵HASP产品的一部分。
许可服务Java组件使用HASP Java本地接口代理与HASP Java本地接口组件通信，这两个组件都是由哨兵提供的。当产品在微软视窗中使用时，HASP Java本机接口可以由HASPJava.dll(32位操作系统)、HASPJava _ x64.dll或HASPJAV _ ia64 . dll(64位操作系统)来表现。
SafeNet Sentinel LDK 6.1许可API包括：
- 有关各个Sentinel Licensing API函数的结构声明和信息，
- XML标记的描述，可用于定义各种API函数的范围和输出格式，
- 所有API返回码的说明。
Sentinel LDK安装包括针对各种编程语言（包括C，C＃，Java）的API示例。 例如，HASP Java API在Aladdin包中包括4个Java类：Hasp，HaspApiVersion，HaspTime和HaspStatus。 这些类捆绑在HASPJava.jar工件中。 HASP Java API类使用System.loadLibrary（）方法从特定于平台的本机库中加载和链接本机方法。 正如我们所说，对于Microsoft Windows，加载的DLL库是HASPJava.dll，HASPJava_x64.dll或HASPJava_ia64.dll之一。
使用Sentinel HASP软件许可安全解决方案的产品的组件图示例。
每个使用Sentinel HASP的软件供应商都将分配一个唯一的批处理代码和相应的供应商密钥。 供应商生成并使用自己的自定义动态库来实现HASP Vendor API（Sentinel Licensing API）。 这些动态库使用供应商密钥作为文件名的一部分来命名。 Windows的API库名称的格式如下：
hasp_windows_ [语言/位] _ [供应商代码]。[库扩展名]
例如，
hasp_windows_x64_99999.dll
是与软件供应商密钥99999相关的64位DLL API库。
在Microsoft Windows中安装Sentinel HASP Runtime时，它还会安装Sentinel HASP Local License Manager，表现为hasplms.exe，并作为本地服务运行。 此服务依赖于TCP / IP协议驱动程序系统组件。 |
