csai200303.pdf

中国系统分析员 2003 年第 3 期 主办单位 主办单位 中国系统分析员协会 出版单位 出版单位 中国系统分析员编辑部 创刊年份 创刊年份 2002 年 主编 主编 张友生 副主编 副主编 马映冰 王 巍 王锦东田俊国 刘 兴 刘 靓 编委 编委 马 荣 王瑛珑 陈建忠 郑泽胜 胡志华 编辑 编辑 何玉云 邓 娟 桂 阳本期责任编辑 本期责任编辑 桂 阳 编辑部 编辑部 地址 地址 湖南师范大学计算机应用技术研究中心 邮政编码 邮政编码 410081 电话 电话 0731-8662005 传真 传真 0731-8662005 主页 主页 http:/www.CSAI 电子投稿 电子投稿 商务洽谈 商务洽谈 网站站长 网站站长 版权声明 版权声明 中国系统分析员电子杂志内所有文章的版权归中国系统分析员杂志社所有，未经允许，杜绝一切转载行为。如需转载者，请直接与编辑部联系。中国系统分析员协会会刊 2003 年 6 月版 第 2 卷第 3 期（总第 7 7 期）目目 录录 协会动态协会动态 主编随笔 田俊国 3 系统分析与设计系统分析与设计 复杂软件驱动系统的 UCM与 UML 殷建民 5面向对象设计需要注意的问题 王晓楠 19Delphi 开发中几种代码复用方式及其比较 简 亮 22 IT 新技术新技术 IPv6 运行环境探讨及过渡策略 王玲芳 李 虹 25 软件测试软件测试 软件测试文档的价值 王 巍 29 解决方案解决方案 电信运营商的 ERP 与 CRM熊绳祖 39 项目管理项目管理 应用模糊逻辑理论度量软件项目的相似度 刘秋林 44 编读往来编读往来 投稿指南 编辑部 57系统分析员考试辅导信息 CSAI 59 中国系统分析员协会（http:/www.CSAI）第 2 页 中国系统分析员 2003 年第 3 期 主编随笔主编随笔 系分协会任重道远 1999 年我在备考系统分析员的时候，系统分析员在我心目中的地位简直可以用神圣二字来形容，甚至超过了教授（事实上二者之间没有可比性，因为搞研究和搞应用是不同的范畴），因为身边有不少教授，但系统分析员却一个也没见过。曾经想遍访当地的系统分析员，打听了当地的软考办，回答却说省上是通过了几个系统分析员，但通过了系统分析员考试的人一般就不会在本省这经济欠发达地区混了，就远走高飞挣大钱去了。所以，我想见一名系统分析员的愿望一直到 2000 年才算勉强实现那就是见到镜中的自己。我说这些，并非刻意渲染系统分析员的水平高和数量少，而是感叹当时系统分析员群体的影响力和信息封闭的状况。终于，在两年前成立了系统分析员协会，通过系统分析员协会的努力，我现在可以轻松得到百余名系统分析员的联系办法，参加系分考试的业界同仁也可得到专门的辅导和培训，这是历史的进步。凭心而论，系统分析员协会自成立以来，一直在健康、稳步地发展。短短两年时间，中国系统分析员协会有了自己的网站、自己的会刊，有了初具规模的会员队伍以及社会的初步认可。而系统分析员不应该是一群容易满足的人，所以这一点成绩绝对不应该成为我们骄傲的资本，但客观评价，如果没有两年前十几个热心肠的有识之士发出成立协会的倡议，没有一批同样有远见的同仁们热情的支持和帮助，恐怕系统分析员还是散落在芸芸众生中的神秘一族。系统分析员协会走过了艰难的破土发芽、从无到有的过程，发展到今天，应该说迎来了成长过程中的第一道坎，那就是如何发展壮大。一个有远大理想的生命，不会默默无闻地自生自灭，而要想方设法发展壮大，让社会感知她，认可她，要通过服务社会、帮助企业成长、帮助从业人员提高水平来实现她的价值。一个人能否有很大的作为，要看他有多强使命感和社会责任感，系分协会也一样。中国的 IT 业与先进发达国家的距离还很大，代表人类智慧的软件出口比例和以聪明自居大中华民族反差很大；中国企业信息化方兴未艾，失败的案例还很多很多，企业花在信息化建设上的冤枉钱太多太多；中国的软件开发还很大程度上没有摆脱作坊式生产的陋俗，还在不断上演软件的设计开发像武林中的武功秘笈一样在一两个脑海里的闹剧。而党的十六大毅然提出“坚持以信息化带动工业化，以工业化促进信息化”的发展策略，这句话背后的压力很大，显然，国家把民族发展的希望很大程度上寄托在信息产业上，就像面对非典的威胁，我们把所有的希望寄托在医护人员身上一样。非典的肆虐，让人们看到医护人员的神圣使命，也让人看到一个个看似平凡的医护人员伟大的风采！而面对信息化带动工业化的民族振兴大略，我们这些IT人是否也有同样强烈的使命感和社会责任感？我们是否想过改变IT业落后现状要从我做起，振兴中华的口号要落实到身边琐碎的具体工作中去？如果普通的 IT 从业人员没这么想也就罢了，但头顶着业界最高桂冠的系统分析员们也不考虑这些，整天想着利用头顶的桂冠去追寻最高的待遇，那可真是民族的悲剧。我一直在想这些年来的高薪是否把我们这些人给宠坏了，缺乏斗志了。所以，我觉得系统分析员协会不应该是一个以盈利为目的的组织，以后也不要想着去盈利，更应该是一个以振兴民族软件产业为己任的志愿者联盟。是一面 IT 人的旗帜，是一个展示 IT 人风采的窗口，是一个通过帮助企业成长、帮助 IT 人才成长来振兴祖国的爱国组织！只有不断强化广大系统分析员使命感，才能最大限度地调动大家的积极性，才可能培育出一中国系统分析员协会（http:/www.CSAI）第 3 页 中国系统分析员 2003 年第 3 期 个高尚的对社会有贡献的系统分析员协会。曾子曰：“士不可以不弘毅，任重而道远。仁以为己任，不亦重乎？死而后已，不亦远乎？”把这句话送给广大系统分析员朋友以共勉。田俊国 2003 年 6 月 18 日 中国系统分析员协会（http:/www.CSAI）第 4 页 中国系统分析员 2003 年第 3 期 复杂软件驱动系统的 UCM 与 UML 复杂软件驱动系统的 UCM 与 UML Daniel Amyot 著 中国系统分析员协会 殷建民 译 摘要：摘要：UCM（Use Case Map）表示法允许以高级因果脚本的方式描述复杂软件驱动系统。通过在抽象组件的结构上添加脚本路径的办法，UCM 提供了系统级的行为与结构的完整视图。本文介绍了 UCM 中的一些与 UML 图相关的有趣特征，还展示了 UCM 如何能够在架构级上将脚本与结构捆绑在一起，如何帮助动态系统可视化，如何支持架构推导，如何帮助在用例与顺序图、活动图、状态图之间的概念缺口上搭建桥梁。1 引言 1 引言 复杂软件驱动系统有许多类型，包括面向对象的、基于代理的、实时的和分布式系统。它们具有下面的许多属性大规模、协同性、分散控制、及时性、可靠性、变化多端特色丰富的功能、运行时组织的流畅性以及系统的升级需求等，这些属性使得它们无论从技术还是从管理复杂性的角度来看都是难以理解的12 25。这些复杂系统经常被用于电信、防卫、宇航和工业控制领域6。统一建模语言（UML）是一种通用目的建模语言，它可用于详细说明和构造软件系统（特别是面向对象的和基于组件的系统）工件并使其可视化与文档化，也可用于商业建模和非软件系统27。它包括用于各种模型描述与文档化的许多概念和表示符，并且拥有技术和工业团体的坚定支持。作为 UML 的重要特色，用例（Use Case）被定义为某一特定用户（执行者）看得见具体结果的系统运行动作序列27。在过去几年里，用于脚本和用例的各种表示法，以及基于它们的设计过程，已经非常流行了。例如，“Rational 统一过程”就是一种用例驱动的（Use-case driven）基于 UML 的方法学。在这种方法中，用例将五类模型（需求、分析、设计、实现和测试）捆绑在一起，这种模型描述了系统的局部表示。UML1.3 允许使用九种不同的图描述复杂软件驱动系统及其模型，每一种图提供了特定角度的模型观点，每一种图在语义上必须与所有其它的图一致。本文中，这些图被分为两类。第一类被称作行为图行为图（Behavioral diagram），主要着眼于系统的功能和动态方面，它由五种类型的 UML 图组成：用例图用例图（Use case diagram）：展示了执行者、用例以及彼此之间的关系，以用户的观点描述系统功能。顺序图顺序图（Sequence diagram）：描述了对象之间按前后次序排列的交互模型，它来源于信息序列流程图。合作图合作图（Collaboration diagram）：展示了系统的总体结构和交互行为。状态图状态图（Statechart diagram）：展示了特定内容的状态空间、引起状态变化的事件以及产生这种结果的动作等。活动图活动图（Activity diagram）：从操作方面捕捉系统的动态行为，着眼于内部进程驱动的流程。第二类被称作结构图结构图（Structural diagram），与系统构件及静态特征有较大关系，它包含四类 UML 图。中国系统分析员协会（http:/www.CSAI）第 5 页 中国系统分析员 2003 年第 3 期 类图类图（Class diagram）：捕捉系统的词汇表，展示了系统的各种实体以及彼此之间的总体关系。对象图对象图（Object diagram）：一个运行系统的“快照”，展示了特定时刻的各种对象实例（带有数据值）以及彼此之间的总体关系。构件图构件图（Component diagram）：展示了软件构件之间的依赖性。配置图配置图（Deployment diagram）：展示了运行时刻进程元素的结构以及与之相伴的软件构件、进程和对象。UML 包含了两类图之间的几种隐含的连接（例如，顺序图和合作图可以使用类图中定义的实体）。但 UML 并没有强调许多系统构件协同工作时（例如，跨越网络的事务处理）出现的大规模行为单元的首要的和紧密的描述方式。本文描述了一种被称为“用例映射图”（Use Case Map，UCM）的制图技术，作为一种以外在的、可视的方式联接行为与结构的手段。UCM 是第一流的架构实体，它描述了捆绑到底层的、组织化的抽象构件结构的各种职能（responsibility）之间的因果关系。本文试图图解 UCM 怎样帮助在用例模型中的用例和分析设计模型中的其它行为图（顺序图、状态图、活动图）之间的概念缺口上搭建桥梁。UCM 还提供了从行为图中的各种活动到结构图中的各种构件（以及对象）组织之间的鸟瞰图，这将使贯穿系统设计发展全过程的架构推导成为可能。虽然本文并不打算成为 UCM 表示法的指南（建议有兴趣的读者参看8 11 13 28以获取更详细的资料），但它图解了 UCM 中对 UML 有潜在帮助的几个特性。第 2 节通过一个简单的电话系统的例子，展示了 UCM 表示法的概貌以及它与用例的关系。第 3 节和第 4 节分别讲述了 UCM 与行为图、状态图的几种关系。第 5 节讨论了 UCM 的现状及其未来的发展。第6 节是整篇论文的结论。2 用例映射图（UCM）2 用例映射图（UCM）2.1 基本表示法 2.1 基本表示法 UCM 用于强调一个系统的最实质、最引人注目的、最关键的功能。沿因果路径的各种职能可以是某一构件内部的、也可以是外部可见的。UCM 可以表现特定的脚本，也可以被抽象，并且可以覆盖多个脚本实例。使用 UCM 时，脚本建立在构件间消息交换的上层，所以它们不必捆绑到特定的组织结构上。UCM 提供了以路径为中心的系统功能视图，并且提高了脚本的可重用性的级别。图 1(d)显示了一个简单的 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）。中国系统分析员协会（http:/www.CSAI）第 6 页 中国系统分析员 2003 年第 3 期 UCM 的构造可以用多种方式完成。例如，一开始可以确定各种职能（图 1(a)），虽然在一个如此简单的图中是不必要的。然后将这些职能分配给脚本（图 1(b)）或构件（图 1(c)）。构件可以沿路径发现。最后，两个视图合并形成约束图（图 1(d)）。图 1(d)是一个相当简单的图，但它以一种紧凑的形式传递了大量的信息，并且允许需求工程师和设计者使用二维信息（结构和行为）选择其系统架构。2.2 附加表示法 2.2 附加表示法 为了进一步介绍 UCM 的符号元素，可以在这个基本用例中增加几项新功能。中国系统分析员协会（http:/www.CSAI）第 7 页 中国系统分析员 2003 年第 3 期 图 2 由图 1 中介绍的实例抽象而来，构件不再涉及 Bob 和lice，而是更一般的主叫方和被叫方（无论用户还是代理）。虚的构件称作“槽”（Slot）,可以由不同时刻的不同实例来填充。这些实例可以扮演构件的某一特定类的角色。在8 11中，Buhr 介绍了一种可处理不同类型的构件和更加丰富的语义（活动进程、被动对象、分组、对象池、中断服务请求、代理、互斥等）的体系化表示法。他还论述了怎样将这些构件与对象类联系起来，由于它们的定义超出了本论文的范围，下面的例子仅仅提供几点直觉的说明，这儿所涉及的构件的自然属性实际上与本论文强调的 UCM 特性并不矛盾。图 2 的中部展示了图 1(d)中 UCM 的增强版，它表现了与用例实例有关的整个类。这种UCM 被称作根图，因为它拥有一些含有各种子图（称作插件）的“容器”（称作桩-Stub）,桩有如下两种：静态桩静态桩:表现为一个普通的菱形（见 ST 桩），它们仅包含一个插件程序，因此允许复杂图的层次分解。动态桩动态桩:表现为一个虚的菱形（见 SO 桩）,它们可能包含几个插件程序，运用时根据选择方针（通常用预设条件描述）确定具体选择，也可能同时选择多个（顺序地或并行地），尽管这样需要 UCM 图之外的更详细的说明。输入和输出桩的路径段已经在根图中标明（斜体标号）。虽然它们并不要求以可视的方式显示出来，但它们的存在有助于完成插件与桩的明确链接。例如，主叫方的 SO 桩有两个插件（ORIGINATING 和 OCS）。ORIGINATING 插件的起点 in1 被接到输入路径段 in1，终点 out1被接到输出路径 out1。为了显示插件和桩之间的清楚的链接关系，图 2 使用了相似的标号。但在通常情况下，名字是不同的，并且这种关系必须明确描述。OCS 插件显示了一个新的构件（被动对象 OCSlist）,它表现为一个屏蔽号码列表，这些号码禁止主叫用户（User O）接通，假如 User O 预订了源呼叫屏蔽服务，则选择 OCS 插件代替 ORIGINATING 插件。在这种情况下，将检查被呼号码是否在屏蔽列表之中（chk）,如果呼叫被拒绝，相应的消息被送回主叫方（md）.TERMINATING 插件在原来的 UCM 的基础上作了一些改进，在被叫方更新（upd）和振铃的同时，返回主叫方一个回铃信号（mrb）。在这儿用一个 AND 分支表示并发性。在 UCM 表示法中，选择性路径（就象 TERMINATING 插件中的 OR 分支、OR 连接）、并发性路径（AND 分支和 AND 连接）、职能共享、例外路径、计时、故障点、错误处理、以及路径之间的同步异步交互作用等，都有相应的命名，除了个别元素之外。通过在集成视图中为桩选择插件，我们可以得到一张展开图，它依然包含了多种可能的头尾相接的脚本。一旦桩被定义为路径上的一个关键点，很容易加入新的插件，这些插件在我们的例子中体现了新的功能。现有的图和插件可以进一步分解或使用新的路径及新的静态桩和动态桩进行进行扩张（例如，当加入一个完全不同的服务时）。2.3 拼版中的 UCM 和用例 2.3 拼版中的 UCM 和用例 UML 用例定义为用例实例的集合，而用例实例则是某一特定执行者看得见具体结果的系统运行动作序列22。用例通常以普通文本的方式描述，虽然有时这种表示法可以被活动图、状态图、预设条件或后置条件等其它行为描述技术所替代。当描述系统和有关的外部执行者之间的交互作用时，用例通常将系统看作内部不可见的黑盒子。由于用例的实现过程体现在行为图中，而在行为图中系统内核被提练为子构件，因此在用例与实现之间存在一个大的概念缺口，使用现行的 UML 图去研究这么一个缺口和这么大的一个图片经常使人迷惑，因为将不同类型的许多图中的许多详细资料集成在一起需要很高的智力。图 3（改编自12）显示了现行 UML 拼版的各块，而 UCM 正是缺少的那块。有了 UCM，中国系统分析员协会（http:/www.CSAI）第 8 页 中国系统分析员 2003 年第 3 期 不再必须将其它块合在一起，不再必须理解这么一张大图。UCM 并不仅仅看作一个附加步骤，更重要的事是，它可以追踪从着眼于系统行为的用例（黑盒）到最终着眼于构件行为的更详细的行为图（玻璃盒）的足迹，因此可以看作一个合理的灰盒（gray box），我们使用“灰盒”这一术语表示某些设计信息是可见的。另外，UCM 表示法还包含一些表达动态情形的功能，它能够以一种紧凑的方式描述整个系统。首先，构件的动态组织可以从代码结构和配置方面抽象出来，用桩、构件池和系统级的动态职能（这里不作讨论）来表示，其次，随时间变化的脚本模型可以用桩和插件表示，如图 2。本文并未宣称使用现行的 UML 图和过程在上述概念缺口上搭建桥梁或表示动态情形是不可能的。但是，UCM 在解决这一迷团使大型图片可视化方面似乎具有独特的优势。下一节进一步图解 UCM 中与现有 UML 图有关的几种优势。3 UCM 和行为图 3 UCM 和行为图 3.1 UCM 和用例图 3.1 UCM 和用例图 用例图显示了角色、用例及其关系。它们特别致力于捕捉用例模型中的功能需求或现有功能，但也可用于其它类型的模型。UML 用例是黑盒描述，而 UCM 更象灰盒，因为它显示了系统的某些细节（例如，抽象构中国系统分析员协会（http:/www.CSAI）第 9 页 中国系统分析员 2003 年第 3 期 件的拓朴结构、动作的内部流程等）。象用例一样，UCM 与系统外部角色通信时（尤其在起点和终点），使用信号、事例和消息，但当 UCM 与系统内部元素通信时，可能使用其它的通信语义。在这一抽象级别上，不会过早地作出系统详细设计的决定。这一决定要留给使用更恰当的表示法（例如顺序图）的其它模型。UML 用例图可以获得用例之间的三类关系，也就是包含关系、扩展关系和归纳关系 22。UCM 表示法在此基础上作了很大的扩展，它以一种紧凑的方式，全面展示了用例及其关系：包含关系包含关系：通过隔离和封装复杂的细节（以便使用例的实际意义明显化）和提高一致性（通过分解包含在几个基用例之中的行为）的办法，目的是帮助阐明一个用例。在基用例路径上放置一个静态桩，就可以实现包含关系。这个桩将其细节隐含在它的插件中（内含用例），而这个插件可以在多个桩中重用，因此改进了 UCM 的一致性。包含点的位置在路径上以可视的方式表述，许多静态桩可以用于表现多种包含。例如，图 2 中的 ST桩和 TERMINATING。扩展关系扩展关系：扩展的目标是表明一个用例的某一部分是（潜在地）可选择的，即在一定条件下（有时是异常条件）才执行一个子流程，或者有一系列的行为段，其中一个或几个可以插入基用例中的扩展点。这种关系在 UCM 术语中用 OR 分支表示，可能有多于两个的选择。OCS 插件的拒绝路径和 TERMINATING 插件的忙路径（图 2）都是它们各自的基用例的扩展。UCM 可使用路径标签、颜色、阴影、加粗等可视化标志强调原始的基用例（以便区分来自可选的或异常事件的基本流程），否则会迷失在繁乱的图中。举个例子，OCS 插件的许可路径（粗线）代表基用例，相反的拒绝路径则是一个扩展。UCM 表示法还为异常的、超时的和错误处理的路径提供了其它的可视化标识。动态桩展示了扩展关系的另一层次。这种桩可能有一个缺省的行为（一个通常包含空路径的插件），它可以被其它插件覆盖。选择某一非缺省插件的条件在选择方针中描述，例如，图 2 中 SO 桩有一个缺省插件（ORIGINATING）。当预订者的 OCS 功能被激活时，OCS 插件取代了缺省插件。UML 用例明确定义了其它行为可以插入的扩展点。UCM 中无此概念，因为任何路径段都是潜在的扩展（例如，一个 OR 分类）的隐含扩展点，而对于动态桩来说则是外在的扩展点。用例归纳用例归纳：当两个或多个用例在行为、结构和目的方面有共同点时，其共享部分随即又可描述为这些子用例所专用的父用例。拥有公共段和公共目标的各种 UCM 脚本可以被集成为 OR 分支和 OR 连接的结合体，或者更有可能被归纳为一个多分支动态桩。父 UCM 代表了原来的用例图中的公共部分，它包含一些拥有行为分支（插件）的动态桩。子 UCM 被父 UCM 所构造，而它的桩被适当的插件所占据。但是，从多个父 UCM 生成子 UCM 时（多重继承），在定义插件以及子 UCM 作用这些插件的方式之前，需要先将各个父 UCM 集成。作为一个例子，一个基本呼叫的 UCM 可以看作是图 2 中根图的简化版，其中缺省的 ORIGINATING 插件占据了 SO 桩，而 TERMINATING 占据了 ST 桩。但一个 OCS 呼叫将在 SO 桩中使用 OCS 插件。无论是基本调用还是 OCS 调用，都是它们的父 UCM（根图）的子 UCM。父UCM 的结构和行为已被子 UCM 继承和修改。3.2 UCM 和交互图 3.2 UCM 和交互图 UML 定义了两类交互图。顺序图顺序图显示了触发事件沿纵向时间轴（称作生命线）的外在顺序，比较适合于实时说明和复杂脚本。合作图合作图显示了实例之间的关系，有助于理解一个给定实例的所有作用，并且有助于程序设计。它们在本质上包含了类似的概念，但以不同方式表中国系统分析员协会（http:/www.CSAI）第 10 页 中国系统分析员 2003 年第 3 期 达。这一节主要着眼于顺序图。UCM 能够帮助从（用例模型中的）用例得到（分析和设计模型中的）交互作用图。UCM并没有明确定义构件之间的消息交换，但消息的构造应使得来自不同构件的职能之间的因果关系明确化。构造消息通常有多种方式，依赖于所用的接口、信道和协议。图 1(d)中 UCM 抽象而来的基用例的因果关系路径,可以作为一个例子。图 4(a)中，这一顺序图被链接到相同的构造层，我们所加入的明确的信道（线）约束了每一消息的潜在发送者与接收者。关于协议与控制的不同决定可以导致多种解决方案。图 4(b)显示了四个并发实体通过简单协议通信产生直接信息交换的情形。但是，假如两个代理之间使用了更复杂的协议（例如，协商协议），并且这一控制被认为是有差别的，那么就该采纳图 4(c)中的源自相同因果关系路径的顺序图。哪个图是最适当的，依赖于设计决定，这一决定并不在 UCM 级别上作出，它需要在具有进一步追踪能力的适当模型中以文档形式表现出来。有几篇论文已经图解了从 UCM 中如何引出有效的消息序列图（MSC）1 4 5。基本的 MSC 实质上与序列图类似。在7中作者介绍了一个从 UCM 到高级 MSC 的映射、一种允许 MSC（带有构造序列的）递归构造的表示法、并发性、可选择性、叠代性以及其它的东西（基本 MSC 有着类似的构造，但对于消息来说，子 MSC 是不同的）。3.3 UCM 和状态图 3.3 UCM 和状态图“状态机”形式上是 Harel 状态图的基于对象的变种15。它混合了 ROOMchart 中定义的几个类似概念，也可看作 ROOM 建模语言的状态图的一个变种24。有了状态图，焦点直接转到了构件行为。UCM 并不替换这些图，但可以指导其构造。UCM脚本中的路径段（可能很多）被连接到一个构件，这个构件需要被集成化以便确定其逻辑和状态。与此同时，覆盖不同构件职能之间的因果关系路径的综合需求被提练为消息交换的形中国系统分析员协会（http:/www.CSAI）第 11 页 中国系统分析员 2003 年第 3 期 式，穿越构件边界的路径段也可以帮助描述构件接口。状态可能被类图中定义的（也可能是独立定义的）可利用的对象类所影响。需要在 UCM 的抽象构件和构造状态机的对象、进程、模块之间建立一种映射。此外，这一综合过程可以导致许多有效的解决方案。因此，设计决定需要在适当模型中被激发（可能被 UCM 之外的需求）并且要以文档的形式表现出来。图 5(a)展示了从图 1(d)穿越构件 Agent B 的 UCM 路径。图 5(b)图示了这一路径的潜在状态图。在这里，职能、保护信息和消息已经分别被映射到状态、条件转换和正常转换。这一特定的例子假定代理有自己的线程，并且在一开始就等待一个特定消息。很明显，不同的假定和需求将导致不同的状态图。从 UCM 路径到状态图的映射并不总是直接的。例如，图 2 的构件将要求更复杂的状态图以便集成多种插件（Agent 0）、集成多种路径起点和终点（Agent O）并且覆盖并发性路径（Agent T）直接从 UCM 产生状态机要迈出很大的步伐，经常用顺序图作为中间步骤。在顺序图这一级别，将做出与提练构件之间因果关系有关的决定。状态机还需要集成这些顺序图以便覆盖每个构件所扮演的不同角色。从 UCM 生成有限状态机的方法，在20中有所介绍，高级 MSC 用作一个中间步骤。UCP还可导向其它类型的通信实体。在1 2 5中，作者使用正式的代数语言 LOTOS18为基于构件的系统行为建模，而代理行为（对于高级原型）则在9 10中生成。3.4 UCM 和活动图 3.4 UCM 和活动图 活动图是状态图的特殊情形，它着眼于内部进程驱动的流程（相互对于普通状态图中的外部事件）。因此，从本质上说，它代表了一个过程或一个商业工作流的状态机。活动图更强调动作顺序和条件而不是执行动作的构件。活动图享有 UCM 的许多概念（甚至于享有 UCM 的许多表示符）。UCM 中的“职能”类似于“活动”。两种表示法都支持动作序列、可选择性和并发性。起点和终点也有类似的用途。一个复杂的活动可以被提练出来成为另一个活动图，正象 UCM 使用桩进行路径分解一样。但桩似乎更通用，桩允许多个输入和输出路径，而且动态桩还准许使用基于某种选择方针的许多插件。在表示复杂系统的动态行为和结构时，UCM 的桩被证明是一个非常有用的创造。UCM 的优势之一体现在职能与构件之间的连接能力。活动图通常并不以这种方式使用，虽然它支持二者之间的有限程度的映射。活动图可以被可视地化分为“泳道”，每条泳道与其相邻的泳道被其两边的纵向实线分离。每一泳道代表了全部活动中的其中一部分职能，最终可由一个或多个对象实现。每个动作被分配到一个泳道。“转移”可能会跨泳道，但转移路径的路由并不明显。泳道可用最简单的形式解释为构件，它们是一维的，并且不以任何方中国系统分析员协会（http:/www.CSAI）第 12 页 中国系统分析员 2003 年第 3 期 式（例如，根据它们的相关位置或真实属性）显示构件之间的关系。UCM 提供了包含这一信息的集成化鸟瞰图。这一鸟瞰图，对于理解表现为路径和（动态）职能的行为如何影响和修改动态系统中构件的运行结构，几乎是必须的。4 UCM 和结构图 4 UCM 和结构图 4.1 UCM 和基于构件的图 4.1 UCM 和基于构件的图 一个 UML 构件图构件图是一个被依赖关系所连接的各种构件的图。某些构件也可能以物理包含的方式连接到另外一些构件，这种物理包含体现了构件之间的复合关系。UML 配置图配置图显示了运行进程元素的结构以及软件构件、进程，还有与其相关的对象。UML 对象图对象图呈现了运行系统的“快照”，因为它展示了某一特定时刻的对象实例及其关系。缺省的 UCM 构件表示法，就象 Buhr 和 Casselman 在8中所定义的那样，具有高度的概括性，它能够展现这三类 UML 结构图中所发现的许多重要特色。它们可以图解包含关系和其它不同类型的（被动的，主动的，等等）依赖关系，甚至于可以展示运行时刻的实例（无数据）。但是，UCM 的主要优势在于它具有以静态图的方式描述动态结构的能力。借助于桩、构件池，以及具有动态职能的 UCM 路径，构件可被创造或撤清，可以四处移动，可以让其它构件看到，等等。带有这种构件的 UCM 可以用一种外表静态和简练的方式表示复杂的动态结果。如果没有 UCM，则需要用 UML 基于构件的图的许多快照来表述。在 UCM 路径下，我们并不阻止其它的结构化表述。这种路径可以用在几类基于构件的图的顶部，就象在 UML 或类似的表示法中一样。4.2 使用 UCM 进行架构推导 4.2 使用 UCM 进行架构推导 UCM 可通过功能（用例）和形式（结构）的连接进行架构选择的早期评估。通过在结构中减弱功能的办法，我们可以将功能与形式同时考虑，也可以分别考虑。前面的 UCM 图图解了相同构件结构的不同路径，UCM 还允许我们重用不同的可选结构中的相同路径。例如图 6(a)象图 4(a)一样重用了相同的因果路径，但是在不同的构件集上。这儿没有涉及通信代理，而是采用不同的依赖机制（例如，通信连接）将职能分配给更加传统的电话构件，如开关和服务节点（SN）。这将依次导向另一个不同集合的有效顺序图和不同的状态机，从而进一步延续设计周期。中国系统分析员协会（http:/www.CSAI）第 13 页 中国系统分析员 2003 年第 3 期 由于 UCM 路径能够很容易地从结构中减弱，从而改进脚本的可重用性，并且导向行为模型，这种模型可以用于广泛的应用软件。在许多场合，UCM 可以提供有帮助性的可视模型，它可以触发关于系统问题的思考和讨论，并且可以被重用11。还应注意到架构选择的评估是在抽象高层进行的，并没有象在顺序图中那样的关于消息与协议的任何早期约定。当潜在的结构被修改时，修改顺序图需要付出更多的努力并可能造成浪费。架构推导还需处理系统需求的改进。复杂系统很少由草图建立，相反，它们是通过不断接收新技术和新功能而不断改进的。正如 Velthuijsen 在29中展示的那样，新功能的增加并不是单调的，它们能够并且将要改变现有功能的操作。新技术也能够改变一些基于功能的假定。UCM 提供了处理系统改进的非单调特性的一种机制（例如，桩和插件），而且还展示了实践中 UCM 如何辩别“分解”（例如，小规模对象、线程、进程、模块、包等）和“分层”（例如，操作系统、信息栈、网络中间件等）81112。这两种体系概念的区分可以帮助处理系统的可升级性和可维护性。5 讨论 5 讨论 5.1 UCM 的语义和工具 5.1 UCM 的语义和工具 UCM 的语义和良好的规则是以超图的方式定义的21。XML 中所表示的 UCM 文本的线性形式31，同样已经被定义3。这种形式适合于不同工具的输入和文档的生成。有了 XML文档类型定义，UCM 与即将制定的 UML 标准可以很容易地集成。这些标准包括 XML 元数据交换（XML）17、UML 交换格式（UXF）26等。UCM 导航器UCM 导航器（一个构造和编辑 UCM 的工具），使用超图语义和规则提供可靠的转换以确保构造正确的图21。这一工具支持路径表示和 Bahr 的构件表示，并且使用 XML 形式作为文件格式。它可用来产生嵌套的桩和插件，可以很容易地将职能连接到构件，可支持代理系统和表演模型的扩展表示，可生成支持 PDF 的 PostScript 文档。这一工具可用于三种平台（Linux、Solaris 和 HP-UX）5.2 UCM 用于正式确认及验证 5.2 UCM 用于正式确认及验证 虽然 UCM 拥有半正式的语义，但能够指导为复杂系统生成更正式的模型和详细说明。最近几年，围绕着从 UCM 引出 LOTOS 详细说明18的问题15，已经作了大量工作。LOTOS是一种代数语言，它甚至可以在缺少构件结构的情况下使 UCM 中发现的事件序列正规化。这将允许需求、规格说明与设计的正式确认及验证，其中的某些东西正是许多面向对象的 CASE工具所缺少的。其它目标形式包括 ROOM724，不久还将包括 SDL219。还应注意，如何使用 ROOM 模型实现 LOTOS 详细说明，这一工作近来还在进行14。UCM 当前被用于几类工程，其中的一些工程处理与动态代理有关的问题910（在描述复杂的代理关系时，UCM 被证明是强大的）、电话间不受欢迎的交互行为的探测与避免5910、功能测试组件的生成、日益涌现的移动电话服务标准的描述等124。建立执行模型是 UCM 的另一应用。在23中，执行变成了路径的一种属性，而不是通常想象的那样，作为整个系统的一种非功能属性。扩展的 UCM 表示法包含了时间戳记、时间的约束、事件分配以及设备进程与任务的联合等。无论是 XML 生成器，还是 UCM 导航器，都支持这些扩展。有关其它类型的非功能需求的集成化问题，也在研究之中。中国系统分析员协会（http:/www.CSAI）第 14 页 中国系统分析员 2003 年第 3 期 5.3 UCM 和 UML 的集成 5.3 UCM 和 UML 的集成 UML 的应用非常广泛，但一般不能有扩展，因为这些扩展可能不被普遍理解、支持和同意。UML 配置文件（profile）提供了在特定领域使用 UML 而无需扩展或修改 UML 的标准使用方式。配置文件是一个预定义的集合，它包括常规、标记值、约束、表示图标等，它们共同剪裁 UML 使其专用于某一特定领域或过程（例如，对象过程模板和商业工程模板）。一个配置文件并不增加新的基本概念以扩展 UML，与此相反，它使标准的 UML 专用于某一特定环境或领域。在 UML 中集成了 UCM 的概念，就可以通过剪裁适当的配置文件实现某些扩展。虽然这样并不要求对 UML 标准作任何修改，但有许多最引人注目的 UCM 概念，很难被现行的 UML 图和语义所覆盖。在UML图集中增加UCM表示法是另一种显而易见的选择。这种办法虽然看起来简单合理，但也因此增加了冗余，而在一个稍微大一点的 UML 图中就存在一些冗余。扩展现有的制图技术（例如，活动图）和语义，支持新颖的 UCM 概念，可以认为是第三种选择。最后，使用 UCM 替换（或改编）一个或多个 UML 图，也被考虑为一个潜在的选择。但由于当前标准和工具的现有投资，这种方法实现起来是很困难的。最好的和最适当的选择，仍然是一个研究话题。然而，独立于具体选择方式的 UCM 概念的标准化的实现，似乎是非常重要的。假如这种标准化能够在不远的未来产生，UML 必定是一个杰出的候选者。6 结论 6 结论 UCM 与现有的 UML 制图技术密切相关，但它帮助填补了用例和行为图之间的概念性（灰盒）缺口。UCM 还展示了关于架构推导的一种人注目的观点，它尤其适合于复杂的和动态的软件驱动系统。在这种系统中，行为从多个构件中不断涌现，通常很难使其可视化。这篇论文图解了关于 UCM 表示法与运用的一些最重要的概念。虽然 UCM 也允许人们独立运用行为图和状态图，但它在系统级上为二者建立了一种有用的连接。通过使用桩、插件和动态构件，UCM 在设计周期的早期，推进了架构推导。未被连接的 UCM 路径成为可重