软件行业和文献中使用术语“组件”来指许多不同的事物。它通常用来泛指“构成其他事物的部分”。它还常用来特指使得能在较大系统中进行替换和装配的特定特征。
在 RUP 中,我们使用术语“组件”来表示系统的封装部分,理论上是系统中相当重要的、几乎独立的可替换部分,它在明确定义的体系结构环境中实现明确的功能。这包括:
-
设计组件 - 重要的设计封装部分,因此包含设计子系统,有时还包含重要的设计类和设计包。
-
实施组件 - 重要的实施封装部分,通常是实施设计组件的代码。
理论上,设计应反映实施,因此您可以只引用组件,每个组件均具有设计和实施。
UML([UML04])如下定义了“组件”:
封装了内容的系统模块化部分,其表现形式在环境中是可替换的。 组件在提供的接口和必需的接口方面定义自己的行为。 这样,组件充当一个类型,其一致性由这些提供的和必需的接口定义(包含它们静态和动态的语义)。
组件被定义为结构化类的子类型,这样,组件就具有属性和操作,能够参与关联关系和泛化关系,并具有内部的结构和端口。 请参阅概念:结构化类以获取更多详细信息。
存在许多适用于组件的 UML 标准构造型,例如用来为大规模组件建模的 <<subsystem>>,以及用来为具有明确规范和实现定义(其中一个规范可以有多个实现)的组件建模的
<<specification>> 和 <<realization>>。
在 RUP 中,术语“组件”的使用要比 UML 的定义广泛。我们并不是仅仅将组件定义为具有诸如模块性、可部署性和可替换性之类的特征,而是建议组件应该具有这些特征。 关于组件可替换性,请参阅下面的部分。
在 RUP 和 UML 术语中,组件应是可替换的。不过,这可能仅仅意味着组件公开了一组隐藏底层实施的接口。
存在其他更强的可替换性类型。它们在下面列出。
源文件可替换性
如果在单个源代码文件内实施两个类,则通常不能分别地为两个编排版本并控制这两个类。
不过,如果一组文件完全实施单个组件,而不实施任何其他组件,那么该组件即为“源文件可替换”。 此特征使得更容易对组件源代码进行版本控制、设置基线以及重用。
部署可替换性
如果两个类在单个可执行文件中部署,那么每个类在已部署的系统中不能独立地替换。
对较大粒度组件期望的特征是“部署可替换”,从而允许部署组件的新版本而无需重新构建其他组件。这通常意味着存在一个文件或一组文件来部署该组件而不部署任何其他组件。
运行时可替换性
如果某个组件可以重新部署到正在运行的系统中,则称为“运行时可替换”。这使得软件能在不损失可用性的情况下进行升级。
位置透明性
具有网络可寻址接口的组件可称为具有“位置透明性”。这使得组件能重新定位到其他服务器,或在多台服务器上复制,以支持故障容忍和负载均衡等等。 这些类型的组件通常称为“分布式”组件或“可分布”组件。
UML 组件是一个建模结构,它提供以下能力:
-
能对类进行分组以定义较大粒度的系统部件
-
能分离可视界面和内部实施
-
能拥有在运行时执行的实例
组件有许多提供的和必需的接口,它们组成了将组件串在一起的基础。 提供的接口是直接由组件实施或者由它的实现类或子组件之一实施的接口,或者是提供的组件端口的类型。
必需的接口由来自组件或者其实现类或子组件的用途依赖关系指定,或者是必需端口的类型。
组件具有借助于公开可见的属性和操作的外部视图(或称为“黑匣”视图)。
(可选)诸如协议状态机之类的行为可以连接到接口、端口以及组件本身,以通过使操作调用序列中的动态约束明确化,来更精确地定义外部视图。组件在系统中或其他环境中的串连可以通过使用组件接口之间的依赖关系来进行结构定义(通常是在组件图上)。
(可选)可以通过在组合结构中使用部件和连接器,来制定更详细的结构协作规范,从而指定组件之间的角色或实例级别协作。 这是组件的内部视图(或称为“白匣”视图),它借助于组件的专用属性,以及实现类或子组件。该视图显示如何内部地实现外部行为。
外部和内部视图之间的映射通过依赖关系完成(在组件图上),或者通过向内部部件委托连接器完成(在组合结构图上)。
RUP 建议将组件用作设计子系统的表示方法。关于详细信息,请参阅工作产品:设计子系统、任务:子系统设计和指南:设计子系统。另请参阅概念:结构化类中的定义。
对于是否在运行时直接实例化组件,没有明确要求。
间接实例化的组件通过一组类、子组件或部件实施或实现。组件本身不出现在实施中,它充当实施必须遵循的设计方案。 实现类、子组件或部件的集合必须涵盖在组件提供的接口中指定的整个操作集。实施组件的方式是实施者的职责。
直接实例化的组件指定其自己的封装实施,它作为可寻址的对象进行实例化。这意味着设计组件在实施语言中具有相应的构造,因此能明确地引用。
UML 1.5 如下定义了“组件”:
系统中模块化的、可部署且可替换的部分,它封装实施,并暴露一组接口。 组件通常由一个或多个驻留在它上面的类或子组件指定,并可以由一个或多个工件(例如二进制文件、可执行文件或脚本文件)实施。
请注意,在 UML 1.3 及更早的 UML 版本中,“组件”表示法用来表示实施中的文件。而在最新的 UML 定义中,文件不再视为“组件”。不过,许多工具和 UML 概要文件仍使用组件表示法来表示文件。请参阅指南:实施元素以获取更多关于在 UML 中表示文件的讨论。
从建模角度来说,组件可与 UML 1.5 中的 UML 子系统相比,因为它们都提供模块性、封装以及能在运行时执行的实例。 RUP 将 UML 1.5 组件建模构造视为表示设计子系统的替代表示法。 关于详细信息,请参阅工作产品:设计子系统和指南:设计子系统。
关于更多信息,请参阅UML1.x 和 UML 2.0 之间的区别。
|