复杂软件驱动系统的UCM与UML

复杂软件驱动系统有许多类型，包括面向对象、基于代理、实时和分布式系统。它们具有许多属性，例如大规模、协同性、分散控制、及时性、可靠性、变化多端及特色丰富的功能、运行时组织的流畅性，以及系统的升级需求等，这些属性使得它们无论从技术还是从管理复杂性的角度来看都是难以理解的。这些复杂系统经常被用于电信、防卫、宇航和工业控制等领域。

UML（统一建模语言）是一种通用目的建模语言，它可用于详细说明和构造软件系统（特别是面向对象和基于组件的系统）工件并使其可视化与文档化，也可用于商业建模和非软件系统。它包括用于各种模型描述与文档化的许多概念和表示符，并且拥有技术和工业团体的坚定支持。

作为UML的重要特色，用例（Use Case）被定义为某一特定用户（执行者）看得见具体结果的系统运行动作序列。在过去几年中，用于脚本和用例的各种表示法，以及基于它们的设计过程已经非常流行了。例如，“Rational统一过程”就是一种用例驱动的（Use-case driven）基于UML的方法学。在这种方法中，用例将5类模型（需求、分析、设计、实现和测试）捆绑在一起，这种模型描述了系统的局部表示。UML 1.3允许使用9种不同的图描述复杂软件驱动系统及其模型，每一种图提供了特定角度的模型观点，每一种图在语义上必须与所有其他图一致。本文中，这些图被分为两类。第1类称为“行为图”（Behavioral diagram），主要着眼于系统的功能和动态方面，它由如下5种类型的UML图组成。

① 用例图（Use case diagram）：展示了执行者、用例以及彼此之间的关系，以用户的观点描述系统功能。

② 顺序图（Sequence diagram）：描述了对象之间按前后次序排列的交互模型，它来源于信息序列流程图。

③ 合作图（Collaboration diagram）：展示了系统的总体结构和交互行为。

④ 状态图（Statechart diagram）：展示了特定内容的状态空间、引起状态变化的事件，以及产生这种结果的动作等。

⑤ 活动图（Activity diagram）：从操作方面捕捉系统的动态行为，着眼于内部进程驱动的流程。

第2类称为“结构图”（Structural diagram），与系统构件及静态特征有较大关系，它包含如下4类UML图。

① 类图（Class diagram）：捕捉系统的词汇表，展示了系统的各种实体及其之间的总体关系。

② 对象图（Object diagram）：一个运行系统的“快照”，展示了特定时刻的各种对象实例（带有数据值）及其之间的总体关系。

③ 构件图（Component diagram）：展示了软件构件之间的依赖性。

④ 配置图（Deployment diagram）：展示了运行时刻进程元素的结构及其与之相伴的软件构件、进程和对象。

UML包含了两类图之间的几种隐含的连接（例如，顺序图和合作图可以使用类图中定义的实体），但UML并没有强调许多系统构件协同工作（例如，跨越网络的事务处理）时出现的大规模行为单元的首要的和紧密的描述方式。

本文描述了一种称为“用例映射图”（Use Case Map，UCM）的制图技术，作为一种以外在且以可视方式连接行为与结构的手段。UCM是第一流的架构实体，它描述了捆绑到底层且以组织化的抽象构件结构的各种职能（responsibility）之间的因果关系。本文试图图解UCM如何帮助在用例模型中的用例和分析设计模型中的其他行为图（顺序图、状态图和活动图）之间的概念缺口上搭建桥梁。UCM还提供了从行为图中的各种活动到结构图中的各种构件（及对象）组织之间的鸟瞰图，这将使贯穿系统设计发展全过程的架构推导成为可能。

1.4.1  用例映射图

1．基本表示法

UCM用于强调一个系统的最实质、最引人注目且最关键的功能，沿因果路径的各种职能可以是某一构件内部，或者外部可见的。UCM可以表现特定的脚本，也可以被抽象，并且可以覆盖多个脚本实例。使用UCM时，脚本建立在构件间消息交换的上层，所以它们不必捆绑到特定的组织结构上。UCM提供了以路径为中心的系统功能视图，并且提高了脚本可重用性的级别。

图1-25所示为一个简单的UCM。

图1-25  一个简单的UCM

其中，一个用户（Alice）试图通过代理网络建立与另一个用户（Bob）之间的电话呼叫。每个用户有一个代理负责管理预订的电话功能，如源呼叫屏蔽（OCS）。Alice首先通过其代理向网络发出连接请求（req），这一请求引起被呼代理检查（vrfy）被呼当事人是“空闲”还是“忙”（图中的“条件”是斜体）。假如空闲，一些状态将被更新（upd）。在Bob一方，振铃信号将被激活；否则一个声明Bob无法通话的消息将准备好（mb）并被回送给Alice（msg）。

脚本以一个触发事件和（或）一个初始条件（标号req的实心圆）开始，以一个或多个结束事件和（或）后继条件（杠）结束（在我们的例子中是ring或msg）。我们将连接原因与结果的路径称为“路由”（route），中间的各种职能（vrfy、upd和mb）沿此路径被激活。可以将职能看做任务或者是被执行的计算功能。在这个例子中，各种职能被分配到不同的抽象构件中（Alice、Agent A、Bob和Agent B等盒子），这些构件可以看做对象、进程、代理、数据库，甚至可以看做角色、执行者或人。我们将这种叠加图称为“约束图”（bound map）。

UCM的构造可以用多种方式完成，例如，开始可以确定各种职能（图1-25（a）），虽然在一个如此简单的图中是不必要的。然后将这些职能分配给脚本（图1-25（b））或构件（图1-25（c））。构件可以沿路径发现。最后，两个视图合并形成约束图（图1-25（d））。

图1-25是一个相当简单的图，但它以一种紧凑的形式传递了大量的信息，并且允许需求工程师和设计者使用二维信息（结构和行为）选择其系统架构。

2．附加表示法

为了进一步介绍UCM的符号元素，可以在这个基本用例中增加几项新功能。

图1-26所示由图1-25中介绍的实例抽象而来，构件不再涉及Bob和Ａlice，而是更为一般的主叫方和被叫方（无论用户还是代理）。虚的构件称为“槽”（Slot），可以由不同时刻的不同实例来填充，这些实例可以扮演构件的某一特定类的角色。下面的例子仅仅提供几点直觉的说明，此处所涉及的构件的自然属性实际上与本论文强调的UCM特性并不矛盾。

图1-26  更复杂的调用连接和新的符号

图1-26的中部展示了图1-25（d）中UCM的增强版，它表现了与用例实例有关的整个类。这种UCM称为“根图”，因为它拥有一些含有各种子图（称为“插件”）的“容器”（称为“桩”），桩有如下两种。

① 静态桩：表现为一个普通的菱形（见ST桩），它们仅包含一个插件程序，因此允许复杂图的层次分解。

② 动态桩：表现为一个虚的菱形（见SO桩），它们可能包含多个插件程序，运用时根据选择方针（通常用预设条件描述）确定具体选择。也可能同时顺序或并行地选择多个，尽管这样需要UCM图之外的更详细的说明。

输入和输出桩的路径段已经在根图中标明（斜体标号），虽然它们并不要求以可视的方式显示，但其存在有助于完成插件与桩的明确链接。例如，主叫方的SO桩有两个插件（ORIGINATING和OCS）。ORIGINATING插件的起点in1连接到输入路径段in1，终点out1连接到输出路径out1。为了显示插件和桩之间的清楚的链接关系，图1-26使用了相似的标号。但在通常情况下，名字是不同的，并且这种关系必须明确描述。

OCS插件显示了一个新的构件（被动对象OCSlist），它表现为一个屏蔽号码列表，这些号码禁止主叫用户（UserO）接通。假如UserO预订了源呼叫屏蔽服务，则选择OCS插件代替ORIGINATING插件。在这种情况下，将检查被呼号码是否在屏蔽列表之中（chk）。如果呼叫被拒绝，相应的消息被送回主叫方（md）。

TERMINATING插件在原来的UCM的基础上做了一些改进，在被叫方更新（upd）和振铃的同时，返回主叫方一个回铃信号（mrb），此处用一个AND分支表示并发性。在UCM表示法中，选择性路径（如同TERMINATING插件中的OR分支和OR连接）、并发性路径（AND分支和AND连接）、职能共享、例外路径、计时、故障点、错误处理，以及路径之间的同步／异步交互作用等都有相应的命名，除了个别元素之外。

通过在集成视图中为桩选择插件，我们可以得到一张展开图，它依然包含多种可能的头尾相接的脚本。一旦桩被定义为路径上的一个关键点，很容易加入新的插件，这些插件在我们的例子中体现了新的功能。现有的图和插件可以进一步分解或使用新的路径及新的静态桩和动态桩进行进行扩张（例如，当加入一个完全不同的服务时）。

3．拼版中的UCM和用例

UML用例定义为用例实例的集合，而用例实例则是某一特定执行者看得见具体结果的系统运行动作序列。用例通常以普通文本的方式描述，虽然有时这种表示法可以被活动图、状态图、预设条件或后置条件等其他行为描述技术所替代。当描述系统和有关的外部执行者之间的交互作用时，用例通常将系统看做内部不可见的黑盒子。由于用例的实现过程体现在行为图中，而在行为图中系统内核被提炼为子构件，因此在用例与实现之间存在一个大的概念缺口。使用现行的UML图去研究这么一个缺口和这么大的一个图片经常使人迷惑，因为将不同类型的许多图中的许多详细资料集成在一起需要很高的智力。

图1-27所示为现行UML拼版的各块，而UCM正是缺少的那块。有了UCM，不再必须将其他块合在一起，并且不再必须理解这么一张大图。UCM并不仅仅被看做是一个附加步骤，更重要的是，它可以追踪从着眼于系统行为的用例（黑盒）到最终着眼于构件行为的更详细的行为图（玻璃盒）的足迹，因此可以看做一个合理的“灰盒”（gray box），我们使用灰盒这一术语表示某些设计信息是可见的。

另外，UCM表示法还包含一些表达动态情形的功能，它能够以一种紧凑的方式描述整个系统。首先，构件的动态组织可以从代码结构和配置方面抽象出来，用桩、构件池和系统级的动态职能（本节不讨论）来表示；其次，随时间变化的脚本模型可以用桩和插件表示，如图1-26所示。

本文并未宣称使用现行的UML图和过程在上述概念缺口上搭建桥梁或表示动态情形是不可能的，但是UCM在解决这一迷团使大型图片可视化方面似乎具有独特的优势。下一节进一步图解UCM中与现有UML图有关的几种优势。

图1-27  UCM作为一个迷宫的缺少部分

1.4.2  UCM和行为图

本节说明UCM和行为图。

1．UCM和用例图

用例图显示了角色、用例及其关系，它们主要致力于捕捉用例模型中的功能需求或现有功能，但也可用于其他类型的模型。

UML用例是黑盒描述，而UCM更类似灰盒，因为它显示了系统的某些细节（例如，抽象构件的拓扑结构和动作的内部流程等）。和用例一样，UCM与系统外部角色通信（尤其在起点和终点）时使用信号、事例和消息。当UCM与系统内部元素通信时，可能使用其他通信语义。在这一抽象级别上，不会过早地做出系统详细设计的决定，这一决定要留给使用更恰当的表示法（例如顺序图）的其他模型。

UML用例图可以获得用例之间的3类关系，即包含关系、扩展关系和归纳关系。UCM表示法在此基础上做了很大的扩展，它以一种紧凑的方式，全面展示了用例及其关系。

① 包含关系：通过隔离和封装复杂的细节（以便使用例的实际意义明显化）和提高一致性（通过分解包含在几个基用例之中的行为）的方法帮助阐明一个用例。

在基用例路径上放置一个静态桩，即可实现包含关系。这个桩将其细节隐含在其插件中（内含用例），而这个插件可以在多个桩中重用，因此改进了UCM的一致性。包含点的位置在路径上以可视的方式表述，许多静态桩可以用于表现多种包含。例如，图1-26中的ST桩和TERMINATING。

② 扩展关系：扩展的目标是表明一个用例的某一部分是（潜在）可选择的，即在一定条件（有时是异常条件）下才执行一个子流程。或者有一系列的行为段，其中一个或几个可以插入基用例中的扩展点。

这种关系在UCM术语中用OR分支表示，可能有多于两个的选择，OCS插件的拒绝路径和TERMINATING插件的忙路径（图1-26）都是其各自基用例的扩展。UCM可使用路径标签、颜色、阴影和加粗等可视化标志强调原始的基用例（以区分来自可选或异常事件的基本流程）；否则会迷失在繁乱的图中。举个例子，OCS插件的许可路径（粗线）代表基用例，而拒绝路径则是一个扩展。UCM表示法还为异常的、超时的和错误处理的路径提供了其他可视化标识。

动态桩展示了扩展关系的另一层次，这种桩可能有一个默认的行为（一个通常包含空路径的插件），它可以被其他插件覆盖。选择某一非默认插件的条件在选择方针中描述，例如，图1-26中SO桩有一个默认插件（ORIGINATING）。当预订者的OCS功能被激活时，OCS插件取代了默认插件。

UML用例明确定义了其他行为可以插入的扩展点，UCM中无此概念。因为任何路径段都是潜在的扩展（例如，一个OR分类）的隐含扩展点，而对于动态桩来说则是外在的扩展点。

③ 归纳关系：当两个或多个用例在行为、结构和目的方面有共同点时，其共享部分随即又可描述为这些子用例所专用的父用例。

拥有公共段和公共目标的各种UCM脚本可以被集成为OR分支和OR连接的结合体，或者更有可能被归纳为一个多分支动态桩。父UCM代表了原来用例图中的公共部分，它包含一些拥有行为分支（插件）的动态桩。子UCM被父UCM所构造，而其桩被适当的插件所占据。但是从多个父UCM生成子UCM（多重继承）时，在定义插件及子UCM作用这些插件的方式之前，需要先将各个父UCM集成。

作为一个例子，一个基本呼叫的UCM可以看做是图1-26中根图的简化版。其中默认的 ORIGINATING插件占据了SO桩，而TERMINATING占据了ST桩，但一个OCS呼叫将在SO桩中使用OCS插件。无论是基本调用还是OCS调用，都是其父UCM（根图）的子UCM，父UCM的结构和行为已被子UCM继承和修改。

2．UCM和交互图

UML定义了两类交互图，其中顺序图显示了触发事件沿纵向时间轴（称为“生命线”）的外在顺序，比较适合于实时说明和复杂脚本；合作图显示了实例之间的关系，有助于理解一个给定实例的所有作用和程序设计。它们在本质上包含了类似的概念，但以不同方式表达。这一节主要着眼于顺序图。

UCM能够帮助从（用例模型中的）用例得到（分析和设计模型中的）交互作用图。UCM并没有明确定义构件之间的消息交换，但消息的构造应使得来自不同构件的职能之间的因果关系明确化。构造消息通常有多种方式，依赖于所用的接口、信道和协议。

图1-25（d）中UCM抽象而来的基用例的因果关系路径<req，vrfy，upd，ring>，可以作为一个例子。如图1-28所示，这一顺序图被链接到相同的构造层，我们所加入的明确的信道（线）约束了每一消息的潜在发送者与接收者，关于协议与控制的不同决定可以导致多种解决方案。

图1-28（b）所示为4个并发实体通过简单协议通信产生直接信息交换的情况。但是假如两个代理之间使用了更复杂的协议（例如协商协议）并且这一控制被认为是有差别的，那么就应该采纳图1-28（c）中的源自相同因果关系路径的顺序图。哪个图是最适当的依赖于设计决定，这一决定并不在UCM级别上做出，它需要在具有进一步追踪能力的适当模型中以文档形式表现出来。

图1-28  从UCM路径中产生的顺序图

3．UCM和状态图

“状态机”形式上是Harel状态图的基于对象的变种，它混合了ROOMchart中定义的多个类似概念，也可看做ROOM建模语言的状态图的一个变种。

有了状态图，焦点直接转到了构件行为。UCM并不替换这些图，但可以指导其构造。UCM脚本中的路径段（可能很多）被连接到一个构件，这个构件需要被集成化以便确定其逻辑和状态。与此同时，覆盖不同构件职能之间的因果关系路径的综合需求被提炼为消息交换的形式，穿越构件边界的路径段也可以帮助描述构件接口。状态可能被类图中定义（也可能是独立定义）的可利用的对象类所影响，需要在UCM的抽象构件和构造状态机的对象、进程和模块之间建立一种映射。此外，这一综合过程可以导致许多有效的解决方案，因此设计决定需要在适当模型中被激发（可能被UCM之外的需求）并且要以文档的形式表现出来。

图1-29（a）所示为从图1-25（d）穿越构件Agent B 的UCM路径，图1-29（b）所示为这一路径的潜在状态图。其中职能、保护信息和消息已经分别被映射到状态、条件转换和正常转换。这一特定的例子假定代理有自己的线程，并且在一开始就等待一个特定消息。很明显，不同的假定和需求将导致不同的状态图。

图1-29  由UCM路径产生的状态图

从UCM路径到状态图的映射并不总是直接的，例如，图1-26的构件将要求更复杂的状态图，以便集成多种插件（Agent 0）、集成多种路径起点和终点（Agent O）并且覆盖并发性路径（Agent T）。

直接从UCM产生状态机要迈出很大的步伐，经常用顺序图作为中间步骤。在顺序图这一级别，将做出与提炼构件之间因果关系有关的决定，状态机还需要集成这些顺序图以便覆盖每个构件所扮演的不同角色。

4．UCM和活动图

活动图是状态图的特殊情形，它着眼于内部进程驱动的流程（相对于普通状态图中的外部事件）。因此从本质上说，它代表了一个过程或一个商业工作流的状态机。活动图更强调动作顺序和条件，而不是执行动作的构件。

活动图享有UCM的许多概念，甚至享有它的多个表示符。UCM中的“职能”类似于“活动”，两种表示法都支持动作序列、可选择性和并发性，起点和终点也有类似的用途。

一个复杂的活动可以被提炼出来成为另一个活动图，正如UCM使用桩进行路径分解一样，但桩似乎更通用。桩允许多个输入和输出路径，而且动态桩还准许使用基于某种选择方针的许多插件。在表示复杂系统的动态行为和结构时，UCM的桩被证明是一个非常有用的创造。

UCM的优势之一体现在职能与构件之间的连接能力，活动图通常并不以这种方式使用，虽然它支持二者之间的有限程度的映射。活动图可以被可视地化分为“泳道”，每条泳道与其相邻的泳道被其两边的纵向实线分离。每一泳道代表了全部活动中的其中一部分职能，最终可由一个或多个对象实现。每个动作被分配到一个泳道。“转移”可能会跨泳道，但转移路径的路由并不明显。泳道可用最简单的形式解释为构件，它们是一维的，并且不以任何方式（例如，根据其相关位置或真实属性）显示构件之间的关系。UCM提供了包含这一信息的集成化鸟瞰图，这一鸟瞰图对于理解表现为路径和（动态）职能的行为如何影响和修改动态系统中构件的运行结构，几乎是必须的。

1.4.3  UCM和结构图

本节说明UCM和结构图。

1．UCM和基于构件的图

一个UML构件图是一个被依赖关系所连接的各种构件的图，某些构件也可能以物理包含的方式连接到另外一些构件，这种物理包含体现了构件之间的复合关系。UML配置图显示了运行进程元素的结构和软件构件、进程，以及与其相关的对象。UML对象图呈现了运行系统的“快照”，因为它展示了某一特定时刻的对象实例及其关系。

默认的UCM构件表示法，如同Buhr和Casselman在中所定义的那样，具有高度的概括性，它能够展现这3类UML结构图中所发现的许多重要特色。它们可以图解包含关系和其他不同类型的（被动或主动等）依赖关系，甚至可以展示运行时刻的实例（无数据）。但是，UCM的主要优势在于它具有以静态图的方式描述动态结构的能力。借助于桩、构件池，以及具有动态职能的UCM路径，构件可被创造或撤销，可以四处移动，可以让其他构件看到等，带有这种构件的UCM可以用一种外表静态和简练的方式表示复杂的动态结果。如果没有UCM，则需要用UML基于构件的图的许多快照来表述。

在UCM路径下，我们并不阻止其他结构化表述。这种路径可以用在几类基于构件的图的顶部，如同在UML或类似的表示法中一样。

2．使用UCM推导架构

UCM可通过功能（用例）和形式（结构）的连接进行架构选择的早期评估。通过在结构中减弱功能的方法，我们可以将功能与形式同时或者分别考虑。前面的UCM图图解了相同构件结构的不同路径，UCM还允许我们重用不同的可选结构中的相同路径。例如图1-30与图1-28（a）一样重用了相同的因果路径，但是在不同的构件集上。此处没有涉及通信代理，而是采用不同的依赖机制（例如通信连接）将职能分配给更加传统的电话构件，如开关和服务节点（SN）。这将依次导向另一个不同集合的有效顺序图和不同的状态机，从而进一步延续设计周期。

图1-30  由UCM路径产生的顺序图

由于UCM路径能够很容易地从结构中减弱，从而改进脚本的可重用性，并且导向行为模型，这种模型可以用于广泛的应用软件。在许多场合，UCM可以提供有帮助性的可视模型。它可以触发关于系统问题的思考和讨论，并且可以被重用。

还应注意到架构选择的评估是在抽象高层进行的，并没有如同在顺序图中那样关于消息与协议的任何早期约定。当潜在的结构被修改时，修改顺序图需要付出更多的努力并可能造成浪费。

架构推导还需处理系统需求的改进，复杂系统很少由草图建立；相反它们是通过不断接收新技术和新功能而不断改进的。正如Velthuijsen描述的那样，新功能的增加并不是单调的，它们能够并且将要改变现有功能的操作，新技术也能够改变一些基于功能的假定。UCM提供了处理系统改进的非单调特性的一种机制（例如桩和插件），而且还展示了实践中UCM如何辨别“分解”（例如小规模对象、线程、进程、模块和包等）和“分层”（例如操作系统、信息栈和网络中间件等），这两种体系概念的区分可以帮助提高处理系统的可升级性和可维护性。

1.4.4  讨论

1．UCM的语义和工具

UCM的语义和良好的规则是以超图的方式定义的。XML中所表示的UCM文本的线性形式，同样已经被定义，这种形式适合于不同工具的输入和文档的生成。有了XML文档类型定义，UCM与即将制定的UML标准可以很容易地集成，这些标准包括XML元数据交换（XML）和UML交换格式（UXF）等。

UCM导航器（一个构造和编辑UCM的工具）使用超图语义和规则提供可靠的转换以确保构造正确的图，这个工具支持路径表示和Bahr的构件表示，并且使用XML形式作为文件格式。它可用来产生嵌套的桩和插件，可以很容易地将职能连接到构件。并支持代理系统和表演模型的扩展表示，可生成支持PDF的PostScript文档。这个工具可用于3种平台（Linux、Solaris 和HP-UX）。

2．UCM用于正式确认及验证

虽然UCM拥有半正式的语义，但能够指导为复杂系统生成更正式的模型和详细说明。最近几年，围绕着从UCM引出LOTOS详细说明的问题，已经做了大量工作。LOTOS是一种代数语言，它甚至可以在缺少构件结构的情况下使UCM中发现的事件序列正规化。因而允许需求、规格说明与设计的正式确认及验证，其中的某些内容正是许多面向对象的CASE工具所缺少的。其他目标形式包括ROOM，不久还将包括SDL。还应注意，如何使用ROOM模型实现LOTOS详细说明，这一工作近来还在进行。

UCM当前被用于几类工程，其中的一些工程处理与动态代理有关的问题（在描述复杂的代理关系时，UCM被证明是强大的）、电话间不受欢迎的交互行为的探测与避免、功能测试组件的生成，以及日益涌现的移动电话服务标准的描述等。

建立执行模型是UCM的另一应用，在有关文献中，执行变成了路径的一种属性。而不是通常想像的那样，作为整个系统的一种非功能属性。扩展的UCM表示法包含了时间戳记、时间的约束、事件分配，以及设备进程与任务的联合等，无论是XML生成器，还是UCM导航器都支持这些扩展。有关其他类型的非功能需求的集成化问题，也在研究之中。

3．UCM和UML的集成

UML的应用非常广泛，但一般不能有扩展，因为这些扩展可能不被普遍理解、支持和同意。UML配置文件（profile）提供了在特定领域使用UML，而无须扩展或修改UML的标准使用方式。配置文件是一个预定义的集合，其中包括常规、标记值、约束和表示图标等，它们共同剪裁UML使其专用于某一特定领域或过程（例如，对象过程模板和商业工程模板）。一个配置文件并不增加新的基本概念以扩展UML；与此相反，它使标准的UML专用于某一特定环境或领域。

在UML中集成了UCM的概念，即可通过剪裁适当的配置文件实现某些扩展。虽然这样并不要求对UML标准做任何修改，但有许多最引人注目的UCM概念，很难被现行的UML图和语义所覆盖。

在UML图集中增加UCM表示法是另一种显而易见的选择，这种方法虽然看起来简单合理，但也因此增加了冗余，而在一个稍微大一点的UML图中就存在一些冗余。

扩展现有的制图技术（例如活动图）和语义，支持新颖的UCM概念，可以认为是第3种选择。

最后，使用UCM替换（或改编）一个或多个UML图，也被考虑为一个潜在的选择。但由于当前标准和工具的现有投资，这种方法实现起来是很困难的。

最好和最适当的选择仍然是一个研究话题，然而独立于具体选择方式的UCM概念的标准化的实现似乎是非常重要的。假如这种标准化能够在不远的未来产生，UML必定是一个杰出的候选者。

1.4.5  小结

UCM与现有的UML制图技术密切相关，但它帮助填补了用例和行为图之间的概念性（灰盒）缺口。UCM还展示了关于架构推导的一种引人注目的观点，它尤其适合于复杂和动态的软件驱动系统。在这种系统中，行为从多个构件中不断涌现，通常很难使其可视化。

这篇论文图解了关于UCM表示法与运用的一些最重要的概念，虽然UCM也允许人们独立运用行为图和状态图，但它在系统级上为二者建立了一种有用的连接。通过使用桩、插件和动态构件，UCM在设计周期的早期推进了架构推导。未被连接的UCM路径成为可重用的脚本模型，它可以连接到多个底层构件的结构中。虽然UCM定义在比消息交换更高的抽象级别上，但它可以指导生成详细的图（例如，顺序图和状态图），甚至生成正式的详细说明。

UCM表示法可以从UCM的许多要领中获益，并已广泛应用于不同的工程，所以变得更稳定、更健壮。UCM工具开始涌现，UCM用户群已初具规模。作为UML拼版中最佳位置的那一块，UCM仍然有待进一步阐明。

致谢

笔者非常感谢Ray Buhr和Luigi Logrippo在过去6年中关于UCM的大量讨论，非常感谢Tom Gray和Darcy Quesnel对于早期草案所提出的有用建议。本研究工作得到了FCAR、NSERC和CITO的部分支持。

笔者非常感谢我的导师——西安交通大学邓良松教授的精心指导与热情帮助。

（《中国系统分析员》2003年第3期  殷建民）

复杂软件驱动系统的UCM与UML