2003 年 8 月 01 日

商业流程执行语言BPEL4WS(Business Process Execution Language For Web Services)是专为整合Web Services而制定的一项规范标准。它从本质上来说是IBM的WSFL和Microsoft的XLANG的结合物，目前已经成为业界标准。WSFL 支持图形化的流程，而XLANG在结构化构造方面有独到的方法，而BPEL4WS正是吸取了两者的优点，同时摒弃了一些复杂繁琐的部分，形成了一种较为自然的描述商业活动的抽象高级语言。
引言

在本文的前三篇文章中(商业流程开发新纪元--BPEL4WS语言介绍，第1部分：特点介绍及使用技巧提示，第2部分：如何有针对性的利用RUP来规范BPEL4WS系统开发流程，BPEL4WS语言介绍，第3部分：利用UML对BEPL4WS系统进行建模)，已经向读者介绍了BPEL4WS语言的主要特点，BPEL4WS主要元素使用技巧以及利用外部Web服务的一些技巧；在软件过程方面着重介绍了在利用BPEL4WS语言进行系统开发时如何合理利用现有成熟软件过程RUP(Rational Unified Process)进行有针对性的系统开发；在BPEL4WS系统建模方面简要介绍了在开发过程中为什么要利用UML(Unified Modeling Language)对BPEL4WS系统进行建模以及如何用UML来构架BPEL4WS系统的体系结构。在本中将向读者介绍如何有针对性的利用UML核心架构对BPEL4WS系统进行建模。希望本文的内容会对您对UML核心架构的理解有所帮助。 

（注：对于BPEL4WS的基本语法介绍以及UML的详细语言规范由于篇幅原因并没有包括在本文中，读者可以参阅附录中的相关资料介绍； 
在文中出现的"BPEL4WS系统"与"用BPEL4WS语言开发的商业系统"同义） 

正文

根据不同系统的不同性质，一些模型可能比另一些模型要重要。例如，对于数据密集型系统，表达静态设计视图的模型将占主导地位。对于图形用户接口密集型系统，静态和动态用况视图就显得相当重要。在实时系统中，动态进程视图尤为重要。而在多层分布式系统中，尤其是在BPEL4WS系统中，实现模型和实施模型相对于其它系统来说就变得更加的重要。 

在利用BPEL4WS语言进行系统开发的过程中利用UML进行建模的方法和对普通的软件系统进行建模的方法大体上是相同的，但由于BPEL4WS系统本身的特点决定了只有针对性地进行建模活动才能取得更有价值的成果，再加上利用UML建模的过程实际上就是在遵循UML Specification的基础上，利用UML提供的一些核心要素对要开发的系统进行可视化、详述、构造和文档化的过程，所以我们可以针对UML的三个基本核心要素(基本构造块、规则、公共机制)来结合BPEL4WS语言的特点来有针对性地进行建模活动。而如何有针对性的利用UML核心架构对BPEL4WS系统进行建模成为了一个重要的问题，在下面的内容中将会较细致的介绍UML中主要元素的特点和如何在建模活动中有倾向性地向BPEL4WS系统靠拢。 

<一>基本构造块

在UML中的基本构造块可以划分为主要的三大类，每一类又可以细分为上图所示的许多小类。对于一个小型的项目来说，也许我们只会用到这些元素的一部分，但对于一个规模较大、较复杂的项目，特别是像BPEL4WS系统这样的多层分布式系统来说，在我们建模的过程中，基本上会用到上面的每一种构造块，只是侧重点要根据项目的特点的不同而定了。在UML的构造块中，我们利用"事物"可以对BPEL4WS模型中最具代表性的成分进行抽象；利用"关系"把BPEL4WS系统中的各种相关事物结合在一起；利用"图"来聚集整个BPEL4WS系统中的相关的事物。接下来让我们来分析每一类基本构造块的特点，以及如何有针对性地利用它们对BPEL4WS系统进行建模。 

<1.1>基本构造块中的4种事物：

<1.1.1>结构事物（Structural thing）：是整个UML模型中的名词。它们通常是模型的静态部分，在BPEL4WS系统中，我们可以利用结构事物来描述一些重要的概念或者物理元素，我们必须能够捕捉到整个BPEL4WS系统中存在的所有的相关的结构事物，只有在完整的系统语义的基础上，我们才可能进一步地发现和得到系统的动态特性。在利用UML建模时，我们一共可以用到7种结构事物，它们分别是： 

类(Class):是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述。我们利用一个类可以实现一个或多个接口。在BPEL4WS系统中，类是最基础的系统构造部分，值得我们多加注意的是我们应该把外部服务抽象成类的概念来进行建模活动，这在后面的类图介绍中会进行解释。 

接口(Interface):是描述了一个类或构件的一个服务的操作集合。因此，接口描述元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。值得我们注意的是，我们只是利用接口定义了一组操作的描述（即特征标记），而不是操作的实现，所有具体的实现都由类或者构件来完成。在BPEL4WS系统中，如果外部的Web服务提供给我们的服务是"暗盒操作"，也就是我们不知道操作的具体内部流程，我们就可以把这些操作抽象到某个接口中，而这些接口由那些抽象成类的Web服务来实现。 

协作(Collaboration):定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他一些相关元素构成的一个群体，这些协作行为从范围上来说要大于所有元素的各自行为的总和。因此，协作是有结构、行为和维度的。要注意的一点是，一个给定的类可以参与几个协作，而这些协作表现了系统构成模式的实现。我们在对BPEL4WS系统建模的时候，在抽象出系统相应的用况之后，就要用协作来实现这些用况，用况就好比是一篇论文的前言，告诉了我们这篇论文是讲什么的，而协作就是具体的内容。 

用况(Use case):是对一组动作序列的描述，系统执行这些动作序列将产生一个对某个特定的参与者有特定价值的结果。我们利用用况来对BPEL4WS模型中的行为事物结构化，我们通常通过协作来实现某一个用况。如果想建立一个完善的BPEL4WS系统模型，用况可以说是至关重要的部分，因为所有的用户需求我们都要在用况中体现出来，可以说用况是开发人员与用户进行交互的窗户，在系统的测试阶段，测试用例的创建也要以用况为基础，不论是BPEL4WS系统还是其他系统，用户满意度才是判断这个系统是否成功的最重要的因素。 

主动类(Active class):是这样的一种特殊的类，其对象至少拥有一个进程或线程，并且它能够启动控制活动。主动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。由于BPEL4WS流程本身就具有主动类的特征（每一个流程拥有自己的进程，并能自动启动控制活动），所以我们可以把流程本身抽象成主动类。 

构件(Component):是整个系统中物理的、可替代的部件，它遵循且提供一组接口的实现。在一个系统中，你将遇到不同类型的部署构件，如 C O M +构件和Java Beans，以及在开发过程中所产生的制品构件，如源代码文件。通常构件是一个描述了一些逻辑元素（如类、接口和协作）的物理包。对于构件在BPEL4WS系统中的使用，我们可以把每一个为我们提供Web服务的服务站点抽象成是一个特殊的"构件"，具体介绍在构件图的介绍中说明。 

节点(Node):是在运行时存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。在一般的系统建模时，如在C/S模式的时候，节点往往就是客户机和服务器；而在N-Tier模式时，也就是多层架构时，除了客户机和服务器外，还要将应用服务器，也就是中间层建模为相应的节点。在BPEL4WS系统中，比较特殊的一点是我们应该将一个服务提供商抽象成是一个节点，在这个特殊的节点中提供了一系列的Web服务，更详细的内容在实施图的说明中介绍。 

<1.1.2>行为事物（Behavioral thing）：是UML模型的动态部分。我们可以把它们看作是模型中的动词，它们描述了系统中存在的行为动作。在利用UML对BPEL4WS系统进行建模时，共有两类主要的行为事物可以供我们使用： 

交互(Interaction):是这样一种行为，它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起行为）和链（对象间的连接）。 

状态机(state machine):是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。 

在这里，由于篇幅关系，只介绍了行为事务的基本概念，在我们对BPEL4WS系统建模的时候，对于行为事务的建模是体现在相应的系统图模型中，这在下面的图模型说明中会有介绍。 

<1.1.3>分组事物（Group thing）：是UML模型的组织部分。它们一般是由整体系统分解下来的小的功能集合。在所有的分组事物中，最主要的分组事物是包，而在对BPEL4WS系统建模时我们利用最多的也是包。 

包(Package):是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件（仅在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在BPEL4WS系统中，包的使用比较自由，我们可以根据自己的需要划分系统中的各个部分，例如可以按外部Web服务的功能来划分这些Web服务。 

(注：包是用来组织UML模型的基本分组事物。它也有变体，如框架、模型和子系统等（它们是包的不同种类）。在JAVA中已经直接支持了包的概念，而在C#中虽然没有明确提出包的概念，但是C#中的命名空间概念实际上与包的概念是一致的) 

<1.1.4>注释事物（Annotation thing）：是UML模型的解释部分。我们可以用注释事物来描述、说明和标注整个UML模型中的任何元素。有一种最主要的注释事物，我们称为注解。 

注解(Note)：是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号。注解可能是大家最容易忽视的部分，当我们编码的时候，程序注释的重要性我想大家都知道，而当我们对BPEL4WS系统或其他系统建模的时候，确容易忘掉为我们建立的系统模型元素加上详细的注释，对一个中小型系统来说，也许并不会有太大的危害，而对于一个复杂的系统模型来说，也许一时的偷懒会造成以后致命的潜伏的错误，所以宁可在建模时放慢进度也要争取建立一个完备的系统模型，为以后的review和测试阶段打下良好的基础。 

<1.2>基本构造块中的4种关系：

依赖（Dependency）： 
是两个事物之间的一种语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在BPEL4WS系统中，我们要善于挖掘系统中存在的依赖关系，如在BPEL4WS系统中，外部Web服务之间就可能存在着依赖关系。 

关联（Association）： 
是一种结构关系，我们用它来描述一组链，链是对象之间的连接。不论是对BPEL4WS系统还是其他系统来说，关联关系恐怕是我们在建模时用到的最多的一种关系，系统元素之间的关系如果不能明显的由其他三类关系来表示，都可以抽象为关联关系。 

(注：聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系) 

泛化（Generalization）： 
是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象，也就是我们在面向对象学中常常提起的继承。用这种方法，子元素共享了父元素的结构和行为。在BPEL4WS系统中，泛化关系的使用并没有什么特殊的地方，只要注意能清楚明了地刻画出系统相关元素之间所存在的继承关系就行了。 

实现（Realization）： 
是UML元素之间的语义关系，其中的一个元素制定了由另一个元素保证执行的契约。在图形上，我们可以把实现看作是泛化和依赖关系两种图形的结合体。 

在BPEL4WS系统中，一般来说，我们会在两个地方需要使用实现关系，一是用在接口和实现它们的类或构件之间，另一种是用在用况和实现它们的协作之间，这些地方都是具有BPEL4WS系统特性的地方，大家在建模的时候要多加注意。 

<1.3>基本构造块中的9种图：

类图（Class diagram）：展现了一组对象、接口、协作和它们之间的关系。 
在对面向对象系统的建模中所建立的最常见的图就是类图。我们可以用类图来给出系统的静态设计视图，我们可以通过主动类的类图给出整个系统的静态进程视图。类图恐怕是大家最熟悉使用的一种图形了，因为自从有了面向对象的理论以后，类和类图就成为最基础的面向对象理论。在对BPEL4WS系统建模的时候，开始时最困难的部分可能就是识别系统中到底有哪些相关对象，也就是抽象出有哪些类，对于识别对象并抽象出类的方法，由于篇幅关系在这里就不详细说了，大家可以参看清华大学出版的一本很有名的书《面向对象的分析》（邵维忠，杨芙清），很实用的教材。在这里要提醒大家注意的是，在BPEL4WS系统中，应该把所有的外部Web服务抽象成类（用版类Stereotype扩展过的），而对于流程本身，也应该抽象成类的概念，这样所有BPEL4WS系统的元素都被抽象成类这种有固定形态特点的事物，这样就为以后的系统动态分析打好了基础。 

对象图（Object diagram）：展现了一组对象以及它们之间的关系。 
对象图描述了在类图中所建立的事物的实例的静态快照。虽然对象图也给出了系统的静态设计视图或者静态进程视图，但它们都是从真实的或原型案例的角度建立起来的。对于BPEL4WS系统的建模来说，对象图并不是重点，因为过细致的对象图会降低系统模型的抽象程度，这是不利于我们从更高的层次理解整个系统的架构和运作，但有的时候对象图也是必不可少的，特别是当我们要表示出位于某个确定状态的类对象之间的关系时。 

用况图（Use case diagram）：展现了一组用况、参与者（一种特殊的类，可以为用户或者是别的系统）及其它们之间的关系。 
我们通常利用用况图给出整个系统的静态用况视图。这些图对于系统的行为进行组织和建模是非常重要的。值得注意的是，在用况图中，我们应该很好地利用用况之间的泛化关系，也就是继承关系，这样可以更清晰地把一个较复杂的商业用况划分为几个较简单的用况（父用况和子用况），这对于我们在BPEL4WS系统中理解一些复杂的商业行为很有好处。 

顺序图（Sequence diagram）： 
在系统中，顺序图是一种强调消息的时间顺序的交互图。对于BPEL4WS系统的建模来说，顺序图应该说是最重要的一种图，虽然顺序图和协作图是同构的，也就是说是可互相转化的，但由于顺序图强调了时间上的概念，这与一个实际商业流程的运作是完全一致的，再加上BPEL4WS系统中所调用的各种外部Web服务在顺序图中可以很好的、形象的表现出来，所以当我们要对具体的商业流程建模的时候，顺序图是我们最好的选择。 

协作图（Collaboration diagram）： 
协作图也是一种交互图，不过它主要强调了收发消息的对象的结构组织的交互图。对于一般的系统建模（如MIS系统）来说，协作图与顺序图是一样重要的，而对于BPEL4WS系统来说，由于我们所关心的商业流程是有时间顺序的，所以我们应该先考虑创建完备的顺序图，对于一些用顺序图表示不太适合的交互（如涉及到复杂的消息传递），我们可以用协作图将其表示出来。 

(注：在这里，我要对交互图作一些补充说明，首先，顺序图和协作图都是交互图，而且顺序图和协作图是同构的，这也就意味着它们是可以相互转换的。另外一点需要注意的事，我们在系统建模的时候应该使交互图专注于整个系统的动态视图，这是因为UML中的交互图本质上展现了一种交互，而这种交互是由一组对象和它们之间的关系组成的，包括了在它们之间可能发送的消息) 

状态图（Statement diagram）：展现了一个状态机，它由状态、转换、事件和活动组成。 
状态图也主要专注于整个系统的动态视图，系统的状态图对于接口，类或协作的行为建模尤为重要，而且它还强调了对象行为的时间顺序，这一点是非常有助于对反应式系统建模的，也就是说对BPEL4WS系统建模来说是非常重要的（因为BPEL4WS系统实际上也带有一部分反应式系统的特点）。在为BPEL4WS系统所建立的模型中，状态图最重要的用处就是为流程本身的状态以及外部Web服务的状态建模。随着流程的运行，系统各个部分的状态可能都会发生变化，我们一定要能捕捉到这些变化，并把这些变化体现在相应的状态图中。 

活动图（Activity diagram）：是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。 
活动图在专注于系统的动态视图的同时，强调了对象间的控制流程，这对系统的功能建模特别的重要。在利用活动图对BPEL4WS系统建模的时候我们要注意，最好能把商业流程中发生的一系列商业事件（如客户身份认证，信用卡号认证等）以一一对应的关系对应到流程的活动图中的每一个活动；如果有必要的话，再对每一个活动进行更深层次的分析，构建出每一个活动本身的交互图和活动图。 

构件图（Component diagram）：展现了一组构件之间的组织和依赖。 
对于构件图，我们首先要知道的是构件图不能反映出系统的动态特性，构件图专注于描述系统的静态实现视图。在我们对任何一个系统建模时（当然包括BPEL4WS系统），构件图不可避免的要与类图相关联，因此我们通常把构件映射成一个或多个类、接口或协作。对于一般的系统来说，大部分的构件都存放在本地系统上，我们可以从大体上把这些构件分为两类，一类是"内部构件"，也就是自己开发的构件；另一类是"外部导入构件"，也就是通常所说的第三方构件，而对于BPEL4WS系统来说，由于它本身的特殊性（对外部Web服务的依赖性）决定了我们在建模时一定要用构件图完整地体现出整个流程所涉及到的所有的外部Web服务以及本地提供的Web服务，我们可以把每一个为我们提供Web服务的服务站点抽象成是一个"构件"，而在这个特殊的"构件"中为我们提供了一系列的Web服务功能。 

实施图（Deployment diagram）：展现了对运行时处理节点以及其中的构件的配置。 
通过构造系统的实施图，我们就可以构造出整个系统体系结构的静态实施视图。在我们对BPEL4WS系统建模的时候，实施图往往都要与构件图相关，通常在系统的每个节点中都包含一个或多个构件。我们可以扩展实施图中节点的概念，在扩展出的新的节点的概念中，一个节点不一定就是一个处理节点，我们可以将一个服务提供商抽象成是一个节点，而一个服务提供商可能会为我们提供几种不同的Web服务（即几个不同的服务站点），那这些服务站点就可以被抽象为"构件"，这样就可以很好的与构件图结合起来对BPEL4WS系统建模。 

(注： 在对BPEL4WS系统建模时，并不限定仅使用这9种图，但这9种图在实际应用中是最常用也是最方便使用的) 

<二>规则

在对BPEL4WS系统建模的时候，我们不能简单地把UML构造块按随机的方式放在一起。像任何语言一样，UML有它自身的一套规则，这些规则描述了一个结构良好的模型看起来应该像什么。对于为BPEL4WS系统所构建的模型，我们要求这个模型应该在语义上是前后一致的，并且与所有的相关模型协调一致。在建模的时候，UML有用于描述如下事物的语义规则： 

命　　名：为事物、关系和图起名。 

范　　围：给一个名称以特定含义的语境。 

可见性：怎样让其他人使用或看见名称。 

完整性：事物如何正确、一致地相互联系。 

执　　行：运行或模拟动态模型的含义是什么。 

值得注意的一点是，当我们对BPEL4WS系统进行建模时除了要建造一些结构良好的模型以外，我们在系统的开发期间所建造的模型往往需要发展变化，并可以由许多人员（所有的项目涉及人即Stakeholders）以不同的方式、在不同的时间进行观察。由于这个原因，下述的情况是常见的，即我们不仅要建造一些结构良好的模型，也要建造一些这样的临时模型： 

省　　　略：隐藏某些元素以简化视图。 

不完全性：可以遗漏某些的元素。 

不一致性：不保证模型的完整性。 

在BPEL4WS系统开发的整个生命期内，随着系统细节的展开和变动，不可避免地要出现这些不太规范的模型。但我们应该时刻牢记，我们的任务是专注于BPEL4WS系统中最重要的分析、设计和实现，而为了解决这些重要问题，将促使我们不断地修改我们所建立的模型、完善我们所建立的模型，这样随着时间的推移和系统设计的深入，我们为BPEL4WS系统所建立的模型将具有更好的结构。 

 <三>公共机制

在UML中有4种贯穿整个语言且一致应用的公共机制，因此使得UML变得较为简单；而特别值得我们注意的是，对于BPEL4WS系统的建模来说，这些机制显得尤为的重要，如果没有这些公共机制，我们是不可能构建出语义上完备的BPEL4WS系统的。这4种公共机制分别是： 

<3.17>详述：在建模的过程中，我们利用UML的图形表示发来对BPEL4WS系统进行可视化，利用UML的详述来描述BPEL4WS系统的细节问题。在文章前面提到的注释的问题实际上就是详述机制的问题，一个完备的BPEL4WS系统不仅要包括完整的系统模型元素，还要有详细的详述才能称得上是一个健壮的系统。 

<3.2>修饰：UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上以扩展其含义。在BPEL4WS系统中，我们可以较自由的对系统中的各个元素进行修饰以扩充其含义，但要注意要保证这种扩充是在受控制的范围中。 

<3.3>通用划分：在对BPEL4WS系统建模时，我们可以采用两种通用划分的手段，一种是对类和对象的划分（类是一个抽象，而对象是这种抽象的一个具体形式）；第二种是对接口和实现的分离（接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实地实现接口的完整语义）。 

<3.4>扩展机制：扩展机制是对已有的UML语义按不同系统的特点合理地进行扩展。 

UML扩展机制包括： 

<3.4.1>构造型（Stereo type）： 
我们在对BPEL4WS系统建模的时候，会发现现有的UML构造块不能完整无歧义地表示出BPEL4WS系统中的每一元素，因此我们可以利用构造型来扩展UML的词汇，我们可以利用它来创造新的构造块，这个新创造的构造块既可以从现有的构造块派生，又专门针对我们要解决的问题。 

<3.4.2>标记值（Tagged value）： 
利用标记值，我们可以扩展UML构造块的特性，我们可以根据我们的需要来创建详述元素的新元素。 

<3.4.3>约束（Constraint）： 
如果我们需要对UML构造块的语义进行扩展，我们就可以使用约束机制，这种机制使我们可以增加新的规则和修改现有的规则。 

(注：由于BPEL4WS系统本身所固有的特点，决定了在我们对其进行建模时不得不对UML中的一些部分进行扩展，但有一点我们必须要注意，那就是我们一定要让我们对UML所作出的扩展保持在我们的控制范围内，简单的说就是我们只可以以受控的方式来进行扩展，而不能任意地、无限制地进行扩展，我们必须保证我们利用UML扩展机制对BPEL4WS系统所作的建模活动是可理解、可控制的，如果任意地扩展，就会使我们在对系统进行建模的过程中偏离利用UML建模的真正目的--信息交流) 

给开发者的建议

"不积跬步无以至千里"，学习掌握UML的过程是一个漫长的过程，有时还会觉得有些乏味，但当你真真掌握了它并灵活的运用它在你的工作中的时候，你就会发现你不曾想到的乐趣。现在UML2.0已经问世了，而BPEL4WS语言也有了新的版本，它们都添加了很多的新的东西，也去掉了一些旧的东西，但我相信本文的内容对于新的Specification来说也是同样适用的，对于新技术新知识我觉得我们应该抱着一种积极的态度去学习和掌握它们，而不应该处于一种被动的状态，越早行动起来就能越早的收到回报，千万不要犹豫不决，就像《谁偷了我的奶酪》中说的那样，让我们都作一只敢于迎接变化的小老鼠吧！ 

结束语

在本文中向读者简要介绍了有关如何有针对性的利用UML核心架构对BPEL4WS系统进行建模的问题。在下一篇文章中，我将会在简要的介绍一些有关商业系统和商业流程的特点之后，为大家举一个实际的例子(贯穿分析，设计和实现)来阐明有关利用BPEL4WS进行系统开发和商业流程架构时应注意的细节问题，例子可能不长，但会涵盖UML中最重要的部分。 

参考资料 

BPEL4WS语言规范 v.1.1 
http://www.ibm.com/developerworks/library/ws-bpel/ 

UML(Unified Modeling Language)语言规范 v.1.5 
http://www.omg.org/technology/documents/formal/uml.htm 

RUP(Rational Unified Process)语言规范 
http://www.rational.com/products/rup/index.jsp