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

复杂软件驱动系统的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期  殷建民）