随着软件系统复杂程度的提高，对好的建模语言的需求也越来越迫切，面向对象建模语言就是应这样的需求而生。其实早在20世纪70年代就陆续出现了面向对象的建模方法，在80年代末到90年代中期，各种建模方法如雨后春笋般从不到10种增加到50多种。
但方法种类的膨胀，使用户很难根据自身应用的特点选择合适的建模方法，极大地妨碍了用户的使用和交流。
在如此众多的方法流派的竞争中，UML（Unified Modeling Language，统一建模语言）举起了统一的大旗。它融合了多种优秀的面向对象建模方法，以及多种得到认可的软件工程方法，消除了因方法林立且相互独立带来的种种不便。它通过统一的表示法，使不同知识背景的领域专家、系统分析和开发人员以及用户可以方便地交流。
它的出现为面向对象建模语言的历史翻开了新的一页，并受到工业界、学术界以及用户的广泛支持，成为面向对象技术领域占主导地位的建模语言。OMG（对象治理组织）采纳它为标准建模语言,进一步将它推向事实上的工业标准的地位，目前它正向ISO（国际标准化组织）提出标准化申请。
尽管目前我国计算机界对UML的推崇程度近乎崇拜，但我们应该客观地熟悉到UML依然存在许多缺憾甚至是错误，需要进一步完善。一个规范的标准化进程总是很漫长，在对它的修订过程中总会不断发现新问题，发现问题、解决问题是个循环反复的过程，在这个过程中，人们不断改进和完善UML。本期专题将追随UML标准化进程的脚步，介绍它修订过程中的每一个进步和缺憾,从而使读者较为客观地了解到UML的现状及未来发展。
UML的现状及未来发展
UML是在多种面向对象建模方法的基础上发展起来的建模语言，主要用于软件密集型系统的建模。它的演化，可以按其性质划分为以下几个阶段：最初的阶段是专家的联合行动，由三位OO（面向对象）方法学家将他们各自的方法结合在一起，形成UML 0.9。第二阶段是公司的联合行动，由十几家公司组成的"UML伙伴组织"将各自的意见加入UML，形成UML 1.0和1.1，并作为向OMG申请成为建模语言规范的提案。第三阶段是在OMG控制下的修订与改进，OMG于1997年11月正式采纳UML 1.1作为建模语言规范，然后成立任务组进行不断的修订，并产生了UML 1.2、1.3和1.4版本，其中UML 1.3是较为重要的修订版。目前正处于UML的重大修订阶段，目标是推出UML 2.0，作为向ISO提交的标准提案。
在多种面向对象建模方法流派并存和相互竞争的局面中，UML树起了统一的旗帜，使不同厂商开发的系统模型能够基于共同的概念，使用相同的表示法，呈现彼此一致的模型风格。而且它从多种方法中吸收了大量有用（或者对一部分用户可能有用）的建模概念，使它的概念和表示法在规模上超过了以往任何一种方法，并且提供了答应用户对语言做进一步扩展的机制。
UML在语法和语义的定义方面也做了大量的工作。以往各种关于面向对象方法的著作通常是以比较简单的方式定义其建模概念，而以主要篇幅给出过程指导，论述如何运用这些概念来进行开发。UML则以一种建模语言的姿态出现，使用语言学中的一些技术来定义。尽管真正从语言学的角度看它还有许多缺陷，但它在这方面所做的努力却是以往的各种建模方法无法比拟的。
从UML的早期版本开始，便受到了计算机产业界的重视，OMG的采纳和大公司的支持把它推上了实际上的工业标准的地位，使它拥有越来越多的用户。它被广泛地用于应用领域和多种类型的系统建模，如治理信息系统、通信与控制系统、嵌入式实时系统、分布式系统、系统软件等。近几年还被运用于软件再工程、质量治理、过程治理、配置治理等方面。而且它的应用不仅仅限于计算机软件，还可用于非软件系统，例如硬件设计、业务处理流程、企业或事业单位的结构与行为建模。
不过UML在取得巨大成功的同时，也不断地受到批评。来自工业界的批评主要是，它过于庞大和复杂，用户很难全面、熟练地把握它，大多数用户实际上只使用它一少部分的概念；它的许多概念含义不清，使用户感到困惑。来自学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题。
目前国内也有不少软件企业在学习并尝试使用UML。从总体上看，我国计算机界对UML的了解还相当初步，但是对它的崇拜程度却远远超过了西方发达国家。人们在学习和使用UML碰到和国外用户相同的疑难和困惑时，却不太敢怀疑UML有什么问题。所以国内几乎没有批评的声音，偶然有一点，也会立即被捍卫的声音沉没，即使对UML一些最明显的缺点和错误也是如此。
相比之下，国际上对UML的讨论和评价则要客观得多。无论是Internet上的意见交流，或是每年一次的UML研讨会，还是学术期刊上发表的文章，都是既肯定其成绩，又指出其缺点和错误，并且以积极的态度提出建设性意见。在酝酿UML下一次的重大发布和筹划UML 2.0作为ISO标准提案的最近两年内，围绕UML的讨论更为活跃和热烈。
为了使我国计算机界对UML目前的状况有较为客观的了解，我们从大量的文献资料中选择了三篇最具权威性的文章，介绍给我国读者。从这组文章中，我们可以得到关于UML现状及未来发展的重要信息：
● UML已经取得重要成功，它已成为在软件工业中占支配地位的建模语言，并在许多领域的软件开发中得到应用。
● UML还存在许多问题，自它产生之日起就从未离开过批评：用户和教师抱怨它内容庞大、难学难教而且太过复杂;学者认为它缺少一个精练的核心和定义良好的外围，有些语义定义得不够精确而且带有二义性;建模实践者认为它缺少支持自己领域建模要求的机制;工具开发商则因为规范本身的不确定性而产生理解上的偏差，它们对UML的自行诠释有可能误导用户。
● UML的要害问题是过于庞大和复杂，以及在语言体系结构、语义等方面存在理论缺陷。产生这些问题的一个重要原因是，在形成规范的过程中不得不照顾多种方法流派的观点和多家公司的利益。
● 为了UML的下一次重大发布，UML 2.0修订的主持者正在广泛收集各方面的意见。各界都给予了很高的关注，提出的意见涉及UML的各个方面。其中一个要害问题是UML是否需要简化，以及如何使之更精练，最终大部分意见是提供一个精练的核心，而把不常用的内容放到定义良好的外围或扩展机制中。此外，UML 2.0还将对UML的底层结构、上层结构和对象约束语言（OCL）做重大改进。
原定UML 2.0在今年某个时间发布，但是在刚刚结束的本年度UML国际研讨会上，没有透露关于该版本最新进度的任何消息，看来它的面世要比预期的日程推后。进入讨论组讨论。
UML 2001：标准化的《奥德赛》史诗
一个规范的标准化进程通常是一个冗长的过程。在UML 1.3的最终草案被批准之际，OMG UML修订任务组和OMG分析设计平台任务组联合主席Cris Kobryn于1999年10月在《COMMUNICATION OF THE ACM》上发表了本文，总结了UML的发展历程，并展望了其发展趋势。
在很短的时间内，UML已经成为软件工业中占支配地位的建模语言。目前它不仅是事实上的建模语言标准，也正在快速地成为法律上的标准。1997年，OMG采纳它作为标准建模语言。现在，OMG正在以ISO公共可用规范提交者的身份，申请将UML规范作为国际标准。
不过，一个规范的标准化进程通常是正式而漫长的，因为它要满足各种各样的技术规范和商业需求。从商业角度看，标准化的时间尺度通常与尽早使用最新技术的竞争需求是冲突的。从技术角度看，为了力求达成共识，则赞成这种"由委员会设计"的进程。
标准化之前的历史
早在1995年，Gray Booch和Janes Rumbaugh将他们的面向对象建模方法统一为Unified Method V0.8。一年之后Ivar Jacobson加入其中，共同将该方法统一为二义性较少的UML 0.9。同时，这三位杰出的方法学家被称为"三友(Three Amigos)"。
很快用户也熟悉到可对软件系统进行可视化、描述、构造和文档化的通用建模语言所带来的益处。他们布满激情地将这种语言的早期草案应用于不同的领域。受用户强烈需求的驱动，建模工具厂商也很快在它们的产品中加入了对UML的支持。
与此同时，UML成了实际上的工业标准。1996年，一个由建模专家组成的国际性队伍"UML伙伴组织"开始同"三友"一起工作，计划将UML提议作为OMG的标准建模语言。
1997年1月，伙伴组织向OMG提交了最初的提案UML 1.0。经过了九个月的紧张修订，于1997年9月提出了最终提案UML 1.1，这个提案在1997年11月被OMG正式采纳为对象建模标准。
有必要指出的是，由于比较仓促地通过了OMG的提交过程，尽管语言的基层结构和大部分上层结构是合理的，UML还是容忍了一些不尽如人意的负面因素：活动图的语义及表示法不完整；标准元素臃肿，其中有些元素是为了满足不同的、相互竞争的方法门派的需求而草率加入的，许多标准元素语义贫乏，而且命名和组织也不一致;结构混乱，所提交的规范并没有达到提交者预期的目标--用一种严格的元模型方法实现4层元模型结构，相反使用了一种实用但不精确的、松散的元模型方法，不利于UML同其他OMG规范的结合，比如与MOF（Meta Object Facility）的结合。
不过提交者们并没有因此推迟UML的标准化进程，而是在该语言的下一个修订版中解决了上述一些问题。
发展进程
OMG为修订标准而提供的基本机制是提案需求（RFP，Request for PRoposals）和修订任务组（RTF，Revision Task Forces）。
其中RFP过程是OMG采纳新规范和改进已有规范的主要机制。任务组发布一个RFP，一个或多个提交团以规范草案作为初始提案响应该RFP，然后任务组对这些初始提案进行评估，并反馈给提交者，鼓励这些提交者与其竞争对手合作，从而形成最终提案。在任务组完成了对最终提案的评估后，就投票决定推荐众多提案中的哪一个。获得多数赞成票的提案就被送交组织委员会和主管该任务组的技术委员会去批准。
假如一个最终提案获得了所有的批准，它就成为被OMG采纳的技术。否则，任务组就有权重新发布一个修改过的RFP。
在一个规范被采纳后不久，将成立一个修订任务组，负责该规范的修订。1997年9月，OMG采纳UML 1.1规范之后不久，特许成立了第一个UML修订任务组，负责收集有关评论，并且提出修改建议。
该RTF提交的第一个主要产品是一个编辑版本UML 1.2，它改编了规范，使之与其他OMG规范更为一致。尽管这一版本纠正了印刷和语法错误，以及某些明显的逻辑上的不一致，但还是没有涉及对重要技术的改进。
该RTF的第二个主要的产品是其技术版本UML 1.3，它修正和改善了UML 1.1的遗留问题，并矫正了在此之后发现的许多小错误。该RTF一致推荐OMG批准其UML 1.3最终草案，并于1999年6月提交了一份最终报告。被推荐的规范随后被提交给组织委员会和平台技术委员会以获得批准。
演变的体系结构
UML是用元模型来描述的，元模型是4层元模型体系结构模式中的一层。此模式的其他层次分别是：元-元模型层、模型层和用户对象层。其中元模型层由元-元模型层导出，UML的元-元模型层在OMG MOF的元-元模型中定义，而UML元模型中的元类是MOF元-元类的实例。
元模型的体系结构模式已被证实可以用来定义复杂模型所要求的精确语义，这种复杂模型通常需要被可靠地保存、共享、操作以及在工具之间进行交换。它的特点如下：
● 它在每一层都递归地定义语义结构，从而使语义更精确、更正规。
● 它可用来定义重量级和轻量级扩展机制，如定义新的元类和构造型。
● 它在体系结构上将UML元模型与其他基于4层元模型体系结构的标准（比如MOF和用于模型交换的XMI Facility）统一起来。
在元模型层，UML元模型又被分解为三个逻辑子包：基础包、行为元素包和模型治理包。其中基础包由核心、扩展机制和数据类型三个子包构成，它是描述模型静态结构的语言底层结构，支持类图、对象图、构件图、部署图等结构图。行为元素包是描述模型动态行为的语言上层结构，支持不同的行为图，包括Use Case（用况）图、顺序图、协作图、状态图和活动图。模型治理包则定义了对模型元素进行分组和治理的语义，它描述了几种分组结构，包括包、模型和子系统。行为元素包和模型治理包都依靠于基础包。
UML 1.3的修订
UML 1.3是建模语言规范第一个成熟的发布。它纠正或调整了从UML 1.1中继续下来的遗留问题，并且修正了最终提交后的一年来所发现的大多数错误。从建模者的角度看，从UML 1.1到UML 1.3并没有很大变化，对语言的大部分改进是在底层对UML元模型语义的调整，只有很少量的变化是针对表示法的细枝末节的修改。底层结构上的变化对大多数用户来说是看不到的，但这使得UML在将来更轻易实现和扩展。
● 解决UML 1.1的遗留问题
完善活动图的语义和表示法 增加了状态的动态激发语义，定义了执行条件线程的语义和表示法，而且增加了对象流功能。为了做这些修订，还需要对活动图所依靠的状态机语义做以下修改:为同步并发的活动加入"同步状态"、精化信号的语义、为合并状态转换定义附加的伪状态。
清理关系的标准元素 引入关系元类来组织各种类型的关系，并且把依靠构造型改造为依靠和流。此外，精练了泛化，不再需要以前的许多构造型（如继续、私有、子类、子类型等）。依靠和其他关系名称的一致性也有所改进。
体系结构的一致性 通过加入物理元模型和XMI(xml metadata Interchange)DTD定义，提高了UML 1.3元模型的体系结构跟MOF和XMI Facility的一致性。从UML语义逻辑元模型导出的物理元模型包含了一些支持产生IDL和XMI DTD的修改（例如将关联类转化为类）。尽管这样做与严格的元模型方法相左，但它为未来UML的修订达到这一目标提供了桥梁。
● 其他变化
静态结构图 放宽了限制，使类和接口之间可以关联，并且在类中可以声明信号。信号被定义为一个类元，可以操作。另外，还重新定义了模板和强类型的语义。
用况图 用况之间的关系被重新定义为三种主要类型：泛化、包含和延伸。
交互图 放宽了限制，使用户可以描述角色或实例。而且协作也可以泛化。
模型治理图 改进了模型和子系统的语义和表示法，将它们从包中分离出来，并使之更轻易使用。澄清了对包的访问和引入权限的区别。
尽管UML规范的核心是语法和语义定义，但它还包括模型交换、语言扩展以及约束等方面的定义。UML 1.3对这些相关规范都进行了错误纠正，并使之与核心语言的改进保持一致。
为UML 2.0确立路标
该RTF在最终报告中明确了因为超出其范围或时间不答应而不能做的各种改进。他们建议下一个RTF应非凡注重扩展性和文档治理方面的问题。对目前的扩展机制，用户和工具开发商已经发现了一些重要问题，而涌入新UML外围的提案可能会加剧这些困难。在文档治理方面，物理元模型和XMI DTD规范的加入大幅度地增加了UML规范的长度，并使它变得笨拙难用（它现在已有800多页了）。下一次UML修订将会把物理建模规范拆分为单独的文档。
该RTF还进一步建议负责起草UML 2.0 RFP的工作组考虑以下问题：
体系结构 使用严格的元模型方法定义一个与MOF元-元模型严格一致的物理元模型。给出改进的指导方针，以决定哪些部分应该定义在核心语言中，哪些部分应定义在UML的外围或标准模型库中。
扩展性 提供同4层元模型体系结构一致的扩展机制。提高外围规范的严密程度，使其支持用户对语言定制能力不断增加的要求。
构件 增强基于构件的软件开发的语义和表示法。
关系 提供"精化"和"追踪"依靠关系的基本语义。在多个抽象层次上定义关联的语义。
状态图和活动图 定义独立于状态图语义的活动图语义。在活动图和状态图中提供更随意的并发。具体说明状态机的泛化。
模型治理 重新定义模型和子系统的表示法和语义，以增强对企业体系结构视图的支持。
总体机制 定义一种模型版本治理的机制。具体说明图的互换机制。
体系结构的十字路口：是雕刻还是糊泥巴？
在UML 1.3最终报告中就体系结构问题强调指出：UML正在靠近OMG体系结构的十字路口。OMG希望通过对体系结构进行改进来完成技术上层结构规范（例如应用框架或商业构件），以补充用于进程间通信和分布式操作系统服务的CORBA底层结构。虽然CORBA IDL对描述分布式计算底层结构非凡有效，它可以用来刻画与界面关联的操作，但却不能用来定义方法、用况、协作、状态机、工作流以及通常与实际商业构件相关的各种关系。
因为UML答应用户定义IDL所缺乏的语义，所以可以用UML来补充IDL。（用UML完全代替CORBA IDL对大多数OMG成员而言变化太剧烈。）然而在这种情况下，对那些想用关系和行为升级IDL结构化规范的人而言，UML将面临如下的挑战：
学习的曲折性 UML是一种通用的建模语言，答应全面的语义表达。但尽管其基本的语言部分很轻易把握，更深层次的内容却需要足够多的时间去学习。
语义臃肿 作为一种通用的建模语言，UML的复杂性和庞大是不可避免的，但其中也包含了大量词义模糊、语义贫乏的标准元素。
轻量级的可扩展性 UML目前仅提供轻量级的扩展机制，如构造型、约束和标记。（相比之下元类是一种重量级的扩展机制。）这些机制将受到一些简单扩展的挑战，例如CORBA IDL接口的构造型，还将受到来自对扩展有更高需求的压力，诸如应用框架和分布式商业构件。
元模型癖好 由于元模型现在被认为是治理复杂的分布式体系结构的强有力技术，许多建模者都渴望用这种新式的重磅大锤来解决本来用砸核桃的锤子（例如构造型）甚至钉大头针的锤子（例如标准模型库中的一个类）就足以解决的问题。
这些挑战要求OMG采用一种雕刻的方法（少即是多）而不是糊泥巴的方法来提炼和扩展UML的体系结构。尤其是OMG需要采取有效的三层结构来决定哪些语言扩展可以处理为对UML核心的修订，哪些可以处理为独立的外围，而哪些可以处理为标准模型库。假如这个三层结构运行正常的话，核心部分将保持或提高其完整性，同时答应自然的选择（借助OMG过程）来遴选最可行的外围和标准化的模型库。进入讨论组讨论。
定义UML核心
面对UML不断增长的系统复杂性和更短的时间限制，新一代的建模者正在致力于消除，而不是增加这个已经很庞大的软件设计标准的复杂性。
这是在2000年6月15日第二次国际年会上，《SOFTWARE DEVELOPMENT》技术编辑Roger Smith在主持完由工业界杰出人物组成的专门小组的圆桌讨论之后得到的结论，并于会后将讨论会的内容组织成本文，发表在《SOFTWARE DEVELOPMENT》上。
在第二次UML国际年会上，《SOFTWARE DEVELOPMENT》技术编辑Roger Smith主持了在下列人士之间展开的圆桌讨论，他们是:Cris Kobryn，OMG UML修订任务组和OMG分析设计平台任务组联合主席；Martin Fowler，Melrose和Mass.-based ThouhgtWorks的首席科学家;Scott Ambler，Ronin国际软件服务咨询公司总裁；Peter Coad，Togethersoft公司的CEO。讨论的焦点是UML的变革途径，即UML的核心是什么，或者说应该是什么，以及如何来扩展它。
SD(software development):Kobryn，什么是UML核心？我们可以怎样扩展它？
Cris Kobryn：你可以将UML的核心看做实质的UML，它可以用来对89%的普通问题建模。该核心可以在元模型层次上用元类或其他具有丰富语义的元实体（相对于具有贫乏语义的元实体而言）来定义。
任何优秀的设计者的设想都是：下一代语言应该从这种语言中精简出来，而不是向其中添加。就是说，当没有东西可添加或者可删除的时候，设计就做完了。
我们对2.0发布版承诺的要害部分是:一个精简的核心，加强可定制性，以及改善对基于构件的开发（比如EJB、CORBA和COM+）的支持。非凡是2.0发布版将从体系结构上精简核心，并使之与其他关于元数据集成和储存的OMG规范（例如元对象设施MOF）更加一致。
此外，对模型治理的支持将有所改进，包括辅助分层、多视点和构件框架。目前的共识是，模型版本治理不属于新版UML的范围。版本和图的交换应该由OMG的另一个结构规范来处理，叫做XMI（即XML Metadata Interchange 格式规范，是一个通过Internet进行对象数据交换的标准协议）。XMI不但可以用来交换模型语义，还可以用来交换模型图。
开发商们对修订会支持到什么程度？很显然建模者希望UML易学易用，UML的复杂性使他们晕头转向，他们指出了很多UML的错误和使用中出现的问题，其中许多都超出了微小修订的范围。用户因为缺少工具支持而经常混淆工具带来的局限和UML规范本身的局限，这使得他们很难明智地、准确地批评UML。UML开发应该是市场驱动的，假如用户要求支持UML 1.3、1.4或2.0，开发商就应该提供。
Scott Ambler:两天前，我和这里的Norm Kerth和Neil Pitman在"UML世界"的一个为期一天的实习班上一起工作，这是我和Norm第三次在这种实习班上工作，有件事引起了我的注重。今年参与的每个人几乎都做了同一件事：他们用了Use Case、顺序图和类图。此后另一个组做了活动图，但那是仅有的不同。而在1999年UML国际会议上，我和Norm教了同样的实习班，使用同样的笔记、同样的讲演，但是那些小组所用的方法要多得多，有些甚至超出了UML的界限。有人使用数据建模，还有人使用屏幕模拟。但是今年没有人做屏幕模拟。这些人都是职业的软件开发者，很有经验，也知道自己在做什么，但他们没有想要超出UML的范围。
Kobryn：Ambler，他们做了一些元模型吗？
Ambler：没有，那正是问题所在。哪怕他们只做了元模型建模，事情也就好办了。学生们也反映到，他们需要一些方法、步骤或是一些关于如何使用UML的指导。客观地说，UML并不是一种方法论或一种过程，但他们的意见恰恰显示了他们赞成所有能真正符合现实世界发展的软件过程。注重我没有提到Rational统一过程（RUP）。
所以我打算持相反的观点，并且要争辩说UML还不够复杂。根据我作为现实世界开发者的经验来看，UML并不充分。我经常问：为了实际交付应用软件，我需要做什么？当我问自己这个问题时，我很快发现UML遗漏了一些可以提供的东西，例如数据模型或用户界面模型，为了交付软件，我几乎天天都要做这些东西。我需要理解用户界面，而且要知道如何存储数据。在UML中我没有看到这些东西。或许Kobryn可以帮助在UML 2.0中注重这一点。
我们也学着对适当的工作采用适当的工具，这些工具可以是白板或纸。而有的时候，我喜欢选用丰满的CASE工具，好的CASE工具可以简化对UML的应用，假如你精通它的使用方式的话。
SD：UML是否应该考虑界面的设计或人类工程学因素？
Peter Coad：在我的印象中，Ambler在很多文献和演讲中提倡这样的观点:UML是一种建模语言，人们可能还要做其他一些事来勾勒出它的结构，例如描绘用户界面设计等。Jared Spool的《网站可用性：设计者指南》就是这方面的一部经典著作，它将用户界面设计和诸如类图、交互图、特征表之类的东西结合起来。但最终将在UML模型中放进这些商业的东西和用户界面吗？这必须是UML的一部分吗？我看不太合适，虽然这是好的工程实践的一部分。
Ambler：我认为UML应该能够描述窗口导航图或用户界面流图。不管怎样，我们在一些Web扩展中看到了这些。假如能将它提取为用户界面元素而不是Web用户界面元素，那就更好了。说实在地，我很怀疑Web外围的必要性。
Martin Fowler：我不同意这样的观点。假如不同的人用不相容的方法做相同的事，那应该在把它放到UML之前去统一它。我并没有看到在用户界面设计方面已经有这方面的尝试。许多有趣的用户界面设计思想正在浮现，但我不认为已经达到可以将其拉到标准中的程度。有些东西虽然重要，但并不意味着它必须进入UML核心。
SD：Fowler，我确信你对此有独到的观点，因为你曾说过你全然没有高估UML工具。你说过你可以用黑板和粉笔做正规的建模。但是否UML正变得太复杂而不适合那样做呢？
Fowler：UML肯定需要简化。不过因为各种技术和人为的因素，简化工作并不是很轻易。现在UML之所以会庞大到这种地步，正是因为一帮方法学家都将他们喜欢的技术加进来。
而当UML日渐成熟，并不是所有好的技术都要成为其中的一部分，UML的威力在于它答应人们做类似的事情并用通用的表示方法来表达。假如人们想做一些不同的东西，例如做Doug Rosenberg的健壮图，我认为不应该把它们并入UML。
即使这样UML还是有些庞大，Kobryn有一项困难的工作摆在面前，那就是要想方设法将核心缩减到最小。因此，我尝试着提出一个核心。我在实践中发现，有三种技术应该包含在UML内：Use Case、类图和交互图，剩下的可以进入某种扩展机制。这样我将其中很多东西都去掉了，不过还有更多需要去除的东西，在Use Case中真正有用的部分是它的文本描述，而Use Case图虽然使用起来很方便，但不是必需的，去掉Use Case图的Use Case严谨而简洁。
有很多符号是为非凡功用而设的，但哪些表示法能满足大多数的需求？我想它们应该是类、属性、操作、关联和泛化。我认为不大应该将交互图去掉，顺序图也用得比较广泛，或许可以去掉协作图，因为目前对它的使用并不多，虽然我也觉得这样有点激进。最后就剩下Use Case的标题、类图和顺序图，足够小了吧？
SD：但是Use Case图很流行，有些人觉得Use Case图是沟通治理者和最终用户的最好方式,对他们来说该怎么办呢？
Fowler：我不是说你只使用我提出的核心，你可以使用任何对你有帮助的技术。实际上，我甚至没有说你应该只用UML。但当我考虑UML核心的时候，我得问，"什么是我能让人轻松接受建模思想的最小数量？"在进行实际建模时并不会只使用核心，我自己也不会。但那是我提议的最低限度。
SD：工具开发商们不应该支持比最低限度更多的内容吗？
Fowler：每一个开发商都应该支持核心和不同的UML扩展片段。而购买者应该能将它们分出层次，并且知道自己需要什么。
Kobryn：将核心与其扩展部分分开并不像人们所想像的那么困难。UML元模型的结构良好，虽然其中有缺陷，但要看怎么说。比如开发商完全或部分地遵守基础语义、行为语义和状态机了吗？他们将语义和表示法分开了吗？有很多这一类的问题，但开发商并不认为自己应该这么做，而用户也没有要求他们这么做。
Coad：为争取更多的人使用UML，OMG可以提供预定义外围的方式。而UML的用户也应该学会选择自己想要的东西，即有较强的能力来定制他们的工具。
SD：我们为什么需要一个UML核心？为什么不把实践这个最重要的东西摆在首位，或者让市场决定呢？
Kobryn:自然选择是可以决定哪些在核心里面，哪些不在，但是我们必须首先处理那些语义贫乏的东西，我的意思是先清理语言本身然后再进行自然选择。此外，因为我们被卷到这个浑身长毛的东西的肠子里，所以一些清理工作必须从体系结构上进行，也要从用户层次上来做。办法就是通过围绕一个核心的若干外围来做这件事，就像Unix的内核思想一样。
SD：假如状态图、活动图等元素不是核心的一部分，工具开发商们会不会找到一种方式，使用他们自己的外围来代替这些元素？
Fowler：我想状态图等工具上的分歧不是问题，状态图作为核心的扩展，是标准的一部分，假如你想支持状态图，你可以将它作为UML标准的一部分来开发。再强调一遍，核心不是整个的UML，重要的是选出一小部分。让开发商来做互不兼容的东西，而当不兼容成为问题时，UML的人就会站出来说："好，让我们统一吧。"事实上，UML的崛起就是由于许多人做了一些相互矛盾的事情，而我们统一了它们。
Kobryn：我同意。UML中某些最丰富的语义与状态图和活动图有关，我们当然不会把孩子和洗澡水一起泼出去。状态图和活动图可以放到外围中，或者通过某种规则将其放到定义良好的元模型扩展中。因此，让我们明确一点:假如你想遵循Fowler和Coad建议的原则做一些简单的事情，你可以把这些原则作为依据。但它的定义必须清楚，这样当用户买一个工具的时候可以知道他得到了什么。
SD:各位愿意看到UML 2.0发布中有些什么呢？
Ambler:我对OMG加入更多的软件工程方法提出异议。我们为什么不首先对我们谈论的这些新的外围设立需求呢？这是我对OMG的异议：首先是需求，然后才是设计。
Fowler:我不觉得UML目前需要很多修改。除了它以外还有很多更重要的东西：好的软件设计原则、理解模式、对软件过程的关注等。最主要的是UML能在一定程度上解决无聊的争论，那时我们就可以转移到更有趣的东西上。
Coad:我发现以小组的方式进行工作能够导致复杂性的瓦解。在17世纪，Blaise Pascal这样写道："我应该写更短的信，但我没时间。"或许现在就是考虑更短书信格式的时候了，这对我们的工作会有所帮助。
Kobryn:假如有团体的支持，核心的实现不是目前需要解决的主要问题。现在应该注重需求，要在几个月内将需求文档定稿，时间已经相当紧迫。它不是指令性的，也不能由任何一个开发商支配，我鼓励每个人都去评论它。我希望已经唤起了这样的公众意识：UML并不一定是你在自己喜欢的建模工具中所实践的那样，问一问你的开发商，至少搞清楚它们的产品是否遵守UML 1.1、1.3或其他版本。最后，我想鼓励你直接参与，把你在RTF划定的范围内不能建模的非凡问题发送给我，我会关注它们。进入讨论组讨论。
UML 2.0之路：快车道还是绕行？
UML已经被迅速和广泛地接受，但UML 1.X系列修订版从来没有离开过批评。在2000年6月国际年会的讨论中，指出了它的很多缺点。这之后UML又经历了几个里程碑，2000年9月，OMG发布了3个UML 2.0提案需求，详述了对下一次重大修订的RFP。今年2月，UML 1.4修订任务组提交了UML 1.4规范的最终草案。对UML 2.0的重大修订到底进行得如何？Cris Kobryn于2001年4月在《SOFTWARE DEVELOPMENT》上发表了本文，分析了UML 1.4的改进以及UML 2.0的修订状况。
最后的1.X系列
在历经17个月的讨论和解决问题之后，第二个UML修订任务组在今年2月结束了它的工作，并提交了一份名为《OMG UML V1.4:修订和建议》的报告。
UML 1.4中最有意义变化的是对外围和扩展机制、构件和制品以及协作和模式方面所做的改动。对外围和扩展机制结构的修订是为了使用户和开发商能正确、有效地定制UML;修正构件建模结构是针对当前基于构件开发的需求;修正协作建模结构则是为了改善语义组织并支持从属协作。
对扩展机制所做的改进包括用图形表示法和表格来描述构造型和标记值定义，对这些表示法的更新是为了支持大而复杂的外围，比如与企业分布式对象计算和企业系统集成RFP的提议相关的那些外围。图1定义了一个构造型《Persistent》，它可以用来具体说明其实例能永久地存储在数据库中的类。《Persistent》基于UML元模型中的元类Class，包括三个用于Table、DB和isContainer的标记定义（同性质列表中的性质相对比）。表1则显示了同一个构造型及其中一个标记定义（Table）的表格形式。
提议对构件的修订则致力于答应建模者在软件生命周期的早期阶段具体说明构件，并且增强了对EJB和COM+的支持。在修订的版本中可以更轻易地区分可执行构件（如EJB Entity Bean、Com Objects等）和实现它们的制品（如EJB JAR文件、DLL等）。图2显示了一个构件图示例，其中包括构件ShoppingCart、Shoppingsession和Catalog。有意思的是ShoppingCart还包括三个借居在其中的类：ShoppingCart、ShoppingCartPK（"PK"表示主要害字）和ShoppingCartInfo。ShoppingCart类用要害词《focus》标记，表明它是类的构造型《focus》的实例。同样地，在ShoppingCartPK和ShoppingCartInfo上的要害字《auxiliary》表明它们都是构造型《auxiliary》的实例，《auxiliary》也是类的构造型。构造型《focus》和《auxiliary》通常成对地使用，用以区别定义核心逻辑或控制流的类（例如中心类）和使用次要的逻辑或控制流的那些类（例如辅助类）。这些构造型对定义类簇通常很有用，非凡是在设计或分析阶段。对构件、模式和框架建模感爱好的读者，可以参考构件工作组的网页（www.celigent.com/omg/umlrtf）。
UML 1.4的最终报告曾提到，由于UML 2.0 RFP的提交工作已经开始，应该考虑把UML 1.4作为UML 1.X系列最后的较小修改版。不过有一个例外，那就是集成UML RFP行为语义的最终提案，这一计划将在完成UML 1.4之后提交UML 2.0初稿之前完成。
修正路标
自去年举行的UML WORLD 2000讨论会以来，在UML的演化上最令人关注的发展之一，就是OMG决定将UML 2.0的工作划分为几个互补的、在系统体系结构上密切合作的RFP：底层结构RFP、上层结构RFP和对象约束语言（OCL）RFP。将需求分类的好处在于使规范成果更加模块化，并能同时进行这些修订。不过这也对维护体系结构的完整性提出更大的挑战，并且会导致更多的集成开销。
1．UML 2.0底层结构RFP
这个RFP致力于改进UML体系结构基础，包括其核心和扩展机制。其他的UML 2.0 RTP 将在此基础上对上层结构和相关的设施（例如图形交互设施）进行修订。这个RFP的需求包括：在体系结构上改进与其他OMG建模规范的接口，例如MOF和XMI;重新构造该语言，使其轻易理解、实现和扩展，当然仍保留已被证实的语义和表示法结构;提供一级扩展机制（非凡是元类）以及与元模型体系结构一致的外围。
2．UML 2.0上层结构RFP
该提案要求改善对软件开发最优方法的支持，例如基于构件的开发、企业过程建模、体系结构建模和可执行的模型。它要求对很多体系结构和行为建模构造进行修订，非凡是在以下领域：
● 改进对基于构件开发的支持，包括构件装配和运行时替换，能具体描述用于主流构件体系结构（例如：EJB和COM+）的执行容器和外围。
● 增强对运行体系结构的支持（与可执行模型相比），包括对层次结构和动态行为的规范。
● 精化关系语义，包括泛化、关联和依靠关系。
● 改进对行为建模的封装和度量，非凡是状态图和交互图。
● 精化与事件治理以及控制和对象流规范相关的活动图语义。
由于上层结构RFP在相当大程度上依靠底层结构RFP，计划底层结构RFP在上层结构RFP之前完成。
3．UML 2.0对象约束语言RFP
本RFP主要关心与UML元模型密切联系的OCL元模型的定义。增加了OCL实现的精确性和一致性，并且便于在UML工具中交换OCL约束。尽管底层结构和上层结构RFP都可能使用OCL描述它们的形式化规则，但它们并不依靠于OCL RFP。
就在本文的写作阶段，OMG又成立了第四个RFP：UML 2.0图交换RFP。其目的是在建模工具之间交互模型图，也包括布局。（UML 1.4模型交换规范是UML 1.4的一部分，但它只描述了语义而没有图交换。）
是快车道还是绕行？
虽然UML 1.X系列的发展势头渐减，UML 2.0正在崛起，但现在猜测UML 2.0的提交过程是否会进展迅速还为时过早。标准化的过程是正式而漫长的，它需要寻求不同范围的技术和商业需求的融合，没有理由认为UML 2.0的提交过程将是一个例外。除了前面已经提到的关于集成多个RFP的问题之外，提交者还会碰到很多其他的挑战，其中包括：
● 在体系结构上与其他的OMG元模型体系结构的协作性 像UML一样，MOF和XMI也在不断改进，因此应该注重修订周期中的协调问题。
● 与元模型相对的外围 在UML 2.0中，一级扩展机制（在用户层次上的元类）的引入，将进一步检验用于描述平台和领域定制语言的方法，这些方法多种多样，而且都很具竞争力。
● 体系结构建模 尽管都认为体系结构是个很好的概念，应该在这方面多做些工作，但对于它是什么以及应该怎样描述它，在工业上达成的一致意见并不多。
● 行为语义的集成性 没有明确将最终提交版与UML RFP的行为语义集成需要做多少工作。
● 在体系结构上与其他规范的结合 例如与SDL－2000和EXPRESS的结合。应从其他规范中借用有用的概念，并在技术上进行综合。
尽管面临很大挑战，但到目前为止，至少在体系结构上已经证实OMG在UML 1.X上的道路是可行的，没有理由怀疑它会在UML 2.X系列中为我们提供有效的指引。进入讨论组讨论。
