【UML用户指南】-16-对高级结构建模-构件

目录

1、概念

2、构件与接口

3、可替换性

4、组织构件

5、端口

6、内部结构

6.1、部件

6.2、连接件

7、常用建模技术

7.1、对结构类建模

7.2、对API建模

---

        构件是系统中逻辑的并且可替换的部分，它遵循并提供对一组接口的实现。好的构件用定义良好的接口来定义灵活的抽象，这样就可能容易用新的兼容构件代替旧的构件。

        接口是连接逻辑模型和设计模型的桥梁。例如，可以为逻辑模型中的一个类定义一个接口，而这同一个接口将延续到一些实现它的设计构件。通过把构件上的端口连接在一起，接口允许用小的构件来建造对大构件的实现。

        可以把应用程序做成一个单一的大单元，但是当需求改变时，它太僵化并很

难修改。此外，也无法利用一些现有的功能。即使一个现存的系统有很多你需要的功能，

它也会有许多你不想要的部分，并且很难或者不可能被剔除。对于软件系统的解决方法类

似于电气系统：把程序做成可灵活连接起来的、定义良好的构件，当需求发生变化时，这

些构件可以单独被替换。

1、概念

1）接口 （interface）是一组操作的集合，其中的每个操作描述了一个由类或构件所请求或者

所提供的服务。

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

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

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

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

件实例。

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

2、构件与接口

几乎所有流行的基于构件的操作系统工具（例如COM+、CORBA和Enterprise Java Beans）都以接口作为把构件绑定在一起的粘合剂。

        基于构件来构造系统，通过描述接口（表示系统中的主要接缝）来分解系统。然后提供实

现这些接口的构件和通过访问接口获得服务的其他构件。这样的机制允许部署一个系统，

它的服务在某种程度上独立于位置，而且（如下一节所述）是可以替换的。

        构件所实现的接口称为供接口（provided interface），意思是构件向其他构件提供的作

为一个服务的接口。一个构件可以声明许多供接口。构件所使用的接口称为需接口

（required interface），意思是一个构件向其他构件请求服务时所遵从的接口。一个构

件可以遵从许多需接口。此外，一个构件可以既有供接口也有需接口。

        构件被表示成右上角标有 图标的矩形。

矩形中有构件的名字。构件可以有属性和操作，但在图中这些经常被省略。

构件可以表示内部结构

可以用两种方式来表示构件和接口之间的关系。

1、第一种方式（最通用的）是用简略的图符形式表示接口。供接口表示成用线连着构件的一个圆（一个“棒棒糖”）。需接口表示成用线连着构件的一个半圆（一个“插口”）。这两种情况下，接口的名字都写在图形符号的旁边。

2、第二种方法是用展开形式来表示，这种方式可以显示出接口的操作。实现接口的

构件用一个完整实现关系连接到接口上。通过接口访问其他构件的服务的构件用一个依赖

关系与该接口相连。

        一个给定的接口可以由一个构件提供，由另一个构件使用。这就形成一个事实：两个构件

间的这种接口打破了构件间的直接依赖关系。不管接口是用什么构件实现的，使用给定接

口的构件都能正常运行。当然，一个构件当且仅当在这样的语境中可以被使用：它的所有

需接口都由其他构件作为其供接口实现了。

3、可替换性

        所有基于构件的操作系统工具的基本目的都是允许用二进制可替换的制品来集成系统。这

就意味着可以用构件来设计系统，然后用制品来实现这些构件，并可以用添加新构件和替

换老构件的方式来更新系统，而无须重新构造系统。 

        构件遵循或提供一组接口的实现，并使逻辑设计和基于其上的物理实现的可替换性成为可能。

        构件是系统的一部分 。构件很少单独存在，相反，一个给定的构件通常与其他构件协作，

并且存在于打算使用它的体系结构或技术语境中。构件在逻辑上和物理上是内聚的，代表

一个较大系统的有意义的结构和（或）行为块。构件可以在多个系统中复用。因此，构件

表示了设计和组成系统的基础构造块。这个定义是递归的，某个抽象层次上的系统可能是

其他更高抽象层次上系统的一个构件。

4、组织构件

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

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

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

5、端口

        端口 （port）是一个被封装的构件的对外窗口。在封装的构件中，所有出入构件的交互都要通过端口。构件对外可见的行为恰好是它端口的总和。此外，端口是有标识的。别的构件可以通过一个特定端口与一个构件通信。

        端口允许把构件的接口划分成离散的并且可以独立使用的包。端口提供的封装性和独立性更大程度上保证了构件的封装性和可替换性。

        端口被表示成跨坐在构件边界上的小方块——它表示一个穿过构件的封闭边界的洞。供接口和需接口都附着到端口符号上。供接口表示一个可以通过那个端口来请求的服务，需接口表示一个该端口需要从其他构件获得的服务。每个端口都有一个名字，因此可以通过构件和端口名来唯一标识它。

构件名和端口名合在一起唯一地标识了一个被其他构件使用的特定构件的特定端口。

部件也有多重性，因此一个构件实例中的一个部件可能对应于多个实例。

上图表示

有两个用于售票的端口，一个供普通用户使用，另一个供优先用户使用。它们都有相同的

类型为Ticket Sales 的供接口。信用卡处理端口有一个需接口，任何提供该服务的构件都

能满足它的要求。节目端口既有供接口也有需接口。使用Load Attractions接口，剧院可

以把戏剧表演和其他节目录入售票数据库以便售票。利用Booking接口，Ticket Seller构

件可以查询剧院是否有票并真正地售票。

6、内部结构

内部结构（包括端口、部件和连接件）

6.1、部件

构件可以被作为一段单独的代码来实现，构件的内部结构是一些部件，这些部件以及它们之间的连接一起组合成构件的实现

部件的图形描述形式与具名、匿名实例一致

部件 （part）是构件的实现单元。部件有名字和类型。在构件实例中，每个部件有一个或多个实例对应于部件指明的类型。部件在其所在构件内有多重性。

上图表明一个编译器构件是由四个部件组成的：一个词法分析器（lexical analyzer）、

一个代码生成器（code generator）、一个语法分析器（parser）和一到三个优化器

（optimizer）。许多编译器的完整版本是由不同层次的优化构成的，在一个给定的版

本中，运行时可以选择一个恰当的优化器。

部件的多重性，在图形展示上必须通过名称来区分，如下图中的normalSales和prioritySales

6.2、连接件

两个端口之间的连线被称作连接件 （connector）。

在整个构件的实例中，它表示一个链或一个暂时链。链是普通关联的实例，暂时链表示两个构件之间的使用关系。暂时链可能由作为操作目标的过程参数或局部变量来提供，而不是普通关联。

连接件有两种表示方式：

第一种方式是：如果两个构件明确地捆绑在一起，无论是直接地还是通过端口，则只在它们之间或它们的端口之间画一条线即可。

第二种方式是：如果两个构件相连是由于它们有能兼容的接口，则可以使用“托球－托座”表示法来表明构件之间没有固定的关系，尽管是在构件内部连接的，可以用满足接口的其他构件来代替。

        也可以将内部端口连接到整体构件的外部端口上，这称为委派连接件，因为外部端口的消息被委派给内部端口。这可以用一个从外部端口指向内部端口的箭头来表示。对此可采取两种看法，第一种看法是把内部端口和外部端口同样对待，它已经被移到边界上并且可以通过它进行观察。第二种看法是，任何传到外部端口的消息被立即传送到内部端口，反之亦然。采用哪一种看法无关紧要，在两种情况下它们行为都是相同的。
 

上图显示了一个带有内部端口和不同种类的连接件的例子。在OrderEntry端口上的外部

请求被委派给 OrderTaking 子构件的内部端口来处理，这个构件进而把它的结果输出到它

的OrderHandoff端口。这个端口用“球－插口”图形符号与OrderHandling子构件相连。

这种连接意味着在两个构件之间无需特别的知识，输出可以被连到任何遵从 OrderHandoff

端口的构件上。OrderHandling构件与Inventory构件通信去查询库中的条目。这被描述为

一个直接的连接件，因为没有任何接口被显示，这试图表明二者之间的结合更紧密。一旦

找到了库中的项目，OrderHandling构件就可以访问外部的Credit（信用卡）服务，这由

连到外部端口charging的委派连接件来显示。如果外部信用卡服务有回应

，OrderHandling构件就与Inventory构件上的ShipItems端口通信，来准备订单以备配送

。Inventory构件访问外部FulFillment服务来真正实现订货。
 

构件图展示了构件的结构和潜在的消息路径。构件图本身并不能通过构件展示消息的序列。序列和其他种类的动态信息可以用交互图来表示。

7、常用建模技术

7.1、对结构类建模

        下图显示了结构类 TicketOrder 的设计，这个类包括四个部件和一个普通属性 price。

customer是Person类的一个对象。customer可以有一个或者没有priority（优先级）状态

，因此priority部件的多重性被表示成0..1，从customer到priority的连接件也具有相同

的多重性。有一个或多个预订坐位，seat具有多重性值。由于customer和seat处在同一个

结构类中，在它们之间就没有必要画一个连接件。注意，Attraction 的边框是用虚线画出

的，这说明，这一部件是对一个不属于这个结构类的对象的引用。该引用随着TicketOrder

类的实例被创建和撤销，但是Attraction的实例是独立于TicketOrder类的。Seat部件与

Attraction的引用相连，因为该订单可能包含针对多个 Attraction（节目）的坐位，而每

个预订坐位都和一个特定的节目相关。从连接件的多重性可以看出每个Seat预订都与正好

一个Attraction对象相连。
 

7.2、对API建模

        对于一个正在将构件组装成系统的开发者，会经常想看到把这些部件粘合到一起的应用程

序编程接口（API）。API代表系统中的程序接缝，可以用接口和构件对它建模。

        识别系统中的接缝，将每个接缝建模为一个接口，并收集形成边界的属性和操作。

只显露那些对于在给定语境中进行可视化来说是比较重要的接口特性，隐藏那些不重要的

特性，必要时可以将这些特性保存在接口的规约中作为参考。    

        下图给出了构件Animator的API，可以看到形成这个API 的 4个接口：IApplication、

IModels、IRendring和IScripts。根据需求，其他构件可以使用一个或多个这样的接口。