UML系列文章（15）---构件

构件是系统中逻辑的并且可替换的部分，它遵循并提供一组接口的实现。

好的构件用定义良好的接口来定义灵活的抽象，这样就可能容易地用新的兼容构件代替旧的构件。

接口是连接逻辑模型和设计模型的桥梁。例如，可以为逻辑模型中的一个类定义一个接口，而这同一个接口将延续到一些实现它的设计构件。

通过把构件上的端口连接在一起，接口允许用小的构件来建造对大构件的实现。

1. 入门

可以把应用程序做成一个单一的大单元，但是当需求改变时，它太僵化并很难修改。此外，也无法利用一些现有的功能。即使一个现存的系统有很多需要的功能，它也有许多不需要的部分，且很难或不可能剔除。对于软件系统的解决方法类似于电气系统：把程序做成可灵活连接起来的、定义良好的构件，当需求发生变化时，这些构件可以单独被替换。

2.术语和概念

接口（interface）是一组操作的集合，它指明了由类或构件所请求或者所提供的服务。

构件（component）是系统中可替换的部分，它遵循并提供了一组接口的实现

端口（port）是被封装的构件的特定窗口，遵循指定接口的构件通过它来收发消息。

内部结构（internal structure）是靠以特定方式连接起来的一组部件来表示的构件实现。

部件（part）是对角色的描述，该角色组成构件的局部实现。在构件的实例中，有相应的部件实例

连接件（connector）是在构件语境中的两个部件或者端口之间的通信关系。

2.1构件和接口

接口是一组操作的集合，用于指明类或构件的一个服务。构件和接口之间的关系是非常重要的。几乎所有 流行的基于构件的操作系统工具（如COM+、CORBA和Enterprise Java Beans）都以接口作为把构件绑定在一起的粘合剂。

基于构件来构造系统，通过描述接口来分解系统。然后提供实现这些接口的构件和通过访问接口获得服务的其他构件。这样的机制允许部署一个系统，它的服务在某种程度上独立于位置，而且可以替换的。

    构件所实现的接口称为供接口（provided interface）意思是构件向其他构件提供的作为一个服务的接口。一个构件可以声明许多供接口。构件所使用的接口称为需接口（required interface），意思是一个构件向其他构件请求服务时所遵从的接口。一个构件可以遵从许多需接口。此外，一个构件可以既有供接口也有需接口。

    构件被表示成右上角标有图标的矩形。矩形中有构件的名字。构件可以有属性和操作，但在图中这些经常被省略。构件可以表示内部机构。

    可以用两种方式来表示构件和接口之间的关系。第一种方式是用简略的图符形式表示接口。供接口表示成用线连着构件的一个圆（一个棒棒糖）。需接口表示成用线连着构件的一个半圆（一个插口）。这两种情况下，接口的名字都写在图形符号的旁边。第二种方法是用展开形式来表示，这种方式可以显示出接口的操作。实现接口的构件用一个完整实现关系连接到接口上。通过接口访问其他构件的服务的构件用一个依赖关系与该接口相连。

    一个给定的接口可以由一个构件提供，由另一个构件使用。这就形成一个事实：两个构件间的这种接口打破了构件间的直接依赖关系。不管接口是用什么构件实现的，使用给定的接口构件都能正常运行。当然，一个构件当且仅当在这样的语境中可以被使用：它的所有需接口都由其他构件作为其供接口实现了。 

2.2 可替换性

    所有基于构件的操作系统工具的基本目的都是允许用二进制可替换的制品来集成系统。这就意味着可以用构件来设计系统。然后制品来实现这些构件，并可以用添加新构件和替换老构件的方式来更新系统，而无须重新构造系统。接口是实现上述方法的关键。在可执行的系统中，可以使用任何实现构件的制品，该构件提供或遵从指定的接口。可以用以下方法扩展系统：使构件通过其他接口提供新的服务，而这些接口又能被其它构件发现和使用。这些语义解释了UML构件定义的背后意图。构件遵循或提供一组接口的实现，并使逻辑设计和基于其上的物理实现的可替换性成为可能。

    构件是可替换的。一个构件可以用遵循相同接口的其他构件来替换。一般情况下，在运行时系统中插入或替换制品的机制对于构件使用者来说是透明的，它通过对象模型或通过自动实现这种机制的工具而成为现实，上述对象模型很少需要或根本不需要人为干预转换。

    构件是系统的一部分。构件很少单独存在，相反，一个给定的构件通常与其他构件协作，并且存在于打算使用它的体系结构或技术语境中。构件在逻辑或物理上是内聚的，代表一个较大系统的有意义的结构或行为块。构件可以在多个系统中复用。因此，构件表示了设计和组成系统的基础构造块。这个定义是递归的，某个抽象层次的系统可能是其他更高抽象层次上系统的一个构件。

    构件是遵从一组接口并提供对这组接口的实现。

2.3 组织构件

    可以用组织类的方式来组织构件，用包将构件分组；

也可以通过描述构件之间的依赖、泛化、关联和实现关系来组织构件。

构件可以由其他构件来构造。

2.4 端口

    接口对构件的总体行为声明是十分有用的，但它们没有个体标识，构件的实现只需要保证它的全部供接口的全部操作都能实现。使用端口就是为了进一步控制这种实现。

    端口是一个被封装的构件的对外窗口。在封装的构件中，所有出入构件的交互都要通过端口。构件对外可见的行为恰好是它端口的总和。此外，端口是有标识的。别的构件可以通过一个特定的端口与一个构件通信。该通信完全是通过由端口支持的接口来描述的。即使这个构件也支持其他的接口。

    端口被表示成跨立于构件边界上的方块，它表示穿过构件的封闭边界的洞。供接口和需接口都附着到端口符号上。供接口表示一个可以通过那个端口来请求的服务，需接口表示一个该端口需要从其他构件获得的服务。每个端口都有一个名字，因此可以通过构件和端口名来唯一标识它。构件内部的部件用端口名来识别要通过哪个端口接收和发送消息。构件名和端口名合在一起唯一地标识了一个被其他构件使用的特定构件的特定端口。

下面是一个带有端口的构件Ticket Seller模型，

    有两个用于售票的端口，一个供普通用户使用，另一个供优先用户使用。它们都有相同的类型为Ticket Sales的供接口。信用卡处理端口有一个需接口，任何提供该服务的构件都能满足它的要求。节目端口既有供接口也有需接口。使用Load  Attractions接口，剧院可以把戏剧表演和其他节目录入售票数据库以便售票。利用Booking接口，Ticket Seller构件可以查询剧院是否有票并真正地售票。

2.5 内部结构

    构件可以作为一段单独的代码来实现，但是在一个大型的系统中，用一些小的构件作为构造块来组建一些大构件。构件的内部结构是一些小的部件，这些部件和它们之间的连接一起组合成构件的实现。在许多情况下，内部部件可以是较小的构件的实例，它们静态地连接在一起，通过端口提供必要的行为而不需要建模者额外地描述逻辑。 

     部件是构件的实现单元。部件有名字和类型。在构件实例中，每个构件都有一个或多个实例对应于部件指明的类型。部件在其所在的构件内有多重性。如果一个部件的多重性大于1，就可能在一个给定的构件实例中有多于1个的部件实例。一个构件实例是和最小个数的部件一起创建的，以后再加入额外的部件。类的属性是一种部件：它有类型和多重性，并且类的每个实例都包含一个或多个给定类型的实例。

上图是一个编译器构件是由四个部件组成：一个词法分析器，一个代码生成器，一个语法分析器和一到三个优化器。 

类型相同的部件

有连接件带端口的部件

 

3.常用建模技术

1）对结构类建模

 

2）对API建模

对于一个正在将构件组装成系统的开发者，会经常想看到把这些部件粘合到一起的应用程序编程接口API。API代表系统中的程序接缝，可以用接口和构件对它建模。

    API本质上是由一个或多个构件实现的接口。作为开发者，实际上只需要考虑接口本身，只要有构件实现这个接口，则哪一个构件实现了接口操作是无关紧要的。但是，从系统的配置管理角度来说，这些实现是很重要的，因为要确保在发布一个API时存在着一些可以完成API职能的实现。幸运的是，在UML中可以对这些建模。

对API建模，要遵循以下原则：

• 识别系统中的接缝，将每个接缝建模为一个接口
• 只显露比较重要的接口特性，隐藏不重要的特性
• 仅当API对于展示特定实现的配置重要时，才对其实现建模。

 

4.提示与技巧 

构件使你能够封装系统的部件来减少依赖，使它们明确而清晰，并且在系统将来必须变化时候能增强其可替换性和灵活性。好的构件能满足以下要求：

• 封装一个具有良好定义的接口和边界的服务
• 拥有充足的值得描述的内部结构
• 不把无关功能结合到一个单元中
• 用少量的接口和端口来组织它的外部行为。
• 只通过所声明的端口进行交互

如果需要嵌套子构件时，应满足：

• 子构件的数量适度
• 确保子构件仅通过定义的端口和连接件进行交互
• 确定哪些子构件直接与外部世界交互，用委派连接件对它们建模。

在用UML绘制一个构件时，要遵循以下策略：

• 给出清晰表明构件用途的名字。接口命名也要表明用途
• 如果子构件或端口类型不能清晰看出含义，则为它们命名
• 隐藏不必要的细节，在构件图中无需显示实现的每个细节
• 用交互图来显示构件的动态方面