在环境变量中设置以下三个变量：
JAVA_HOME=C:\j2sdk1.4.1 //可以改为相应的目录
CLASSPATH=%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\dt.jar
PATH=%JAVA_HOME%\bin;%PATH%

然后在命令行输入java -version命令，如果出现
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
则说明已经配置成功！

HelloWorld.java源程序如下：
public class HelloWorld{ 
 public static void main(String[] args) {  
  System.out.println("Hello World!"); 
  }
}

在命令行执行javac HelloWorld.java
如果没有输出任何信息则说明编译成功。

在命令行运行java HelloWorld，输出：
Hello World!
代表成功执行了java程序。

-----------------
初学者常犯的错误
-----------------

1. 运行时，带了.class后缀
如果你试图使用如下命令：
E:\java\src>java HelloWorld.class
系统会误认为你运行的是HelloWorld包下的名为class的类文件，会到系统的CLASSPATH下（一般都包括当前目录）企图寻找HelloWorld.class.class这样的类，这样的类当然不存在了；并且也不可能存在，因为class是关键字，不能作为一个类的名字。所以会报如下错误信息：
Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld/class

2. 文件名大小写错误
对于像Windows这样的系统，编译时可以不关心大小写。比如编译HelloWorld.java时，也可以使用：
E:\java\src>javac helloworld.java
也可以编译通过，但产生的类文件仍然是和源文件相符的：HelloWorld.class。
但在运行时一定要注意大小写，比如试图使用如下命令运行：
E:\java\src>java helloworld
将报类似于1中的错误：
Exception in thread "main" java.lang.NoClassDefFoundError: helloworld (wrong name: HelloWorld)

----------------------------
包含包层次的HelloWorld.java
----------------------------

比如上面的HelloWorld.java修改如下：
package org.javaresearch;
public class HelloWorld{
public static void main(String[] args) {
System.out.println("Hello World!"); 
}
}

编译时有两种方法

1. 直接编译
E:\java\src>javac HelloWorld.java
此时在当前目录下输出HelloWorld.class。此时，运行不能使用上面相同的方法，使用：
E:\java\src>java HelloWorld
运行时，出现如下错误：
Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld (wrong name: org/javaresearch/HelloWorld)
从上述错误信息你也可以看到，系统可以找到HelloWorld类（因为当前路径包含在CLASSPATH中，具体为什么会提示wrong name，有兴趣的朋友参见Java语言规范），但这个类属于org.javaresearch包。所以，你要做的就是按照上述包层次，相应的创建目录层次，把上面生成的HelloWorld.class放到E:\java\src\org\javaresearch\目录下。运行：
E:\java\src >java org.javaresearch.HelloWorld
系统打印出：
Hello World!
这儿要注意的是，不能使用java org\javaresearch\HelloWorld来运行，此时同样会出现如下错误：
Exception in thread "main" java.lang.NoClassDefFoundError:org\javaresearch\HelloWorld (wrong name: org/javaresearch/HelloWorld)

2. 使用 -d <directory>编译选项
是不是觉得上面的编译方法有点麻烦，能不能自动在当前路径（或任意指定的路径）下生成包层次呢？有！使用-d <directory>编译选项就能做到。
E:\java\src >javac -d . HelloWorld.java
此时，在当前目录下就生成了一个org\javaresearch目录，并且输出的.class文件也在里面。运行：
E:\java\src >java org.javaresearch.HelloWorld
系统打印：Hello World!
如果你想把生成的类文件集中存放在一个目录中，比如：E:\java\classes下，那么你首先创建这个目录，然后编译时：
E:\java\src >javac -d E:\java\classes HelloWorld.java
就可以把生成的类文件放到E:\java\classes目录下，并且按照包层次相应的创建目录路径。你可以在E:\java\classes\org\javaresearch下找到HelloWorld.class文件。此时使用如下命令可以正确运行（注意如果要用到其它类，请在CLASSPATH中设好）：
E:\java\classes >java org.javaresearch.HelloWorld

或者你可以在E:\java目录下面运行以下命令来执行
E:\java >java -classpath .\classes org.javaresearch.HelloWorld
使用java的-classpath参数可以将一些目录加入类路径

-------------------
打包jar文件
-------------------
可以把一个包内的所有class文件打包为一个jar文件，便于存放和运行。以上文的org.javaresearch包为例，其打包命令如下：
E:\java\classes >jar cvf wxb.jar org
会生成一个wxb.jar文件，将其中META-INF\MANIFEST.MF文件中添加如下一行：
Main-Class: org.javaresearch.HelloWorld
保存jar文件。

或者首先创建并编辑一个MANIFEST.MF文件，其内容如下：
Manifest-Version: 1.0
Created-By: 1.4.1 (Sun Microsystems Inc.)
Main-Class: org.javaresearch.HelloWorld
将其保存到classes目录中
然后将其一起打包到jar文件中，打包命令如下：
E:\java\classes >jar cvfm wxb.jar MANIFEST.MF org

-------------
运行jar文件
-------------
在命令行中输入如下命令即可：
E:\java\classes >java -jar wxb.jar
输出为：
Hello World!

------------------------
用Ant来编译运行java程序
------------------------
首先安装Ant，步骤很简单：
1.将Ant压缩包解压到一个目录，例如D:\Ant1.5.2；
2.在环境变量中添加以下变量：
ANT_HOME=D:\Ant1.5.2  //可以改为相应的目录
3.修改Path环境变量
PATH=%ANT_HOME%\bin;%PATH%

最后给出了一个Ant的build.xml文件，运行ant即可完成所有以上的编译和运行过程，其build文件如下：
<project name="HelloWorld" default="jar" basedir=".">
    <description>
        building HelloWorld!
    </description>
  <!-- set global properties for this build -->
  <property name="src" location="src"/>
  <property name="build" location="classes"/>
  <property name="dist"  location="dist"/>
  <property name="user.name" value="Wang Xuebin"/>

  <target name="init">
    <!-- Create the time stamp -->
    <tstamp/>
    <!-- Create the classes directory structure used by compile -->
    <mkdir dir="${build}"/>
  </target>

  <target name="build" depends="init"  description="build the source code" >
    <!-- Compile the java code from ${src} into ${build} -->
    <javac srcdir="${src}" destdir="${build}"/>
  </target>

  <target name="jar" depends="build"
        description="generate the distribution" >
    <!-- Create the distribution directory -->
    <mkdir dir="${dist}/lib"/>

    <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
  <jar destfile="${dist}/HelloWorld-${DSTAMP}.jar" basedir="${build}">
   <manifest>
    <attribute name="Built-By" value="${user.name}"/>
    <attribute name="Main-Class" value="org.javaresearch.HelloWorld"/>
   </manifest>
  </jar> 
 </target>
 
  <target name="run" depends="build" description="run HelloWorld">
    <java classpath="${build}" classname="org.javaresearch.HelloWorld"></java>
  </target>

  <target name="runjar" depends="jar" description="run HelloWorld in jar file">
         <java jar="${dist}/HelloWorld-${DSTAMP}.jar"
           fork="true"
           failonerror="true"
           maxmemory="128m"
           >
         <arg value="-h"/>
         <classpath>
           <pathelement location="${dist}/HelloWorld-${DSTAMP}.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>
  </target>
 
  <target name="clean"
        description="clean up" >
    <!-- Delete the ${build} and ${dist} directory trees -->
    <delete dir="${build}"/>
    <delete dir="${dist}"/>
  </target>
</project>

本文主要分析了 Michael Wahler 的博士论文研究计划书 [1] ，他是 IBM Zurich 研究室的一名走读博士。他的导师是 David Basin 。他的研究题目是关系型模型转换方法的形式化。我将其中有意义的部分摘录出来。并加上了一些自己的想法和观点。这份计划书是 2004 年写的，其中一些想法和观点今天看来也不失偏颇。

今天又搜索了一下 Michael Wahler 的论文，发现他除了这一篇以外，没有以第一作者的身份发表论文。很是遗憾，他的博士论文计划书做得很好，为什么没有成果出来呢？

（蓝色部分是自己的观点和评论。）

Background and Definitions

在第一部分 Background and Definitions 中，给出了四个概念 Model 、 Transformation 、 Consistency between Models 、 Reconciliation 。这些概念和其它地方的概念有一些区别，解释如下：

Model ：   A model is a representation of a part of the function, structure and/or behavior of an application or system. A representation is said to be formal when it is based on a language that has a well-defined form (”syntax”), meaning (”semantics”), and possibly rules of analysis, inference, or proof for its constructs. The syntax may be graphical or textual.

模型是一个应用程序或者系统的功能，结构或者行为部分的一种表达方式。当一种表达方式基于一种含有良构的形式（语法），含义（语义），以及关于分析、推论或者证明其构造的规则的语言时，这种表达方式被称为形式化的。其语法可以是图形的或者是文本的。

事实上，目前对于软件模型的形式化表达，例如类图的形式化表达还是没有一个统一的标准或者语言。

Transformation ：

Functional View ： A transformation is a function that maps a tuple of models from one or more

domains onto another tuple of models in the same or different domains.

Operational View ： A transformation is a terminating algorithm that applies structural and/or

semantic changes to a model or a set of models.

对于模型转换有两种观点：

功能的观点：一个转换是一个函数，它可以将一组模型从一个或者更多的领域映射到相同或者不同领域中的另一组模型。

操作的观点：一个转换是一个可停机算法，它将结构或者语义的变化应用到一个或者一组模型。

描述性（ declarative ）的模型转换语言就是基于功能的观点；而命令性（ imperative ）的模型转换语言则是基于操作的观点。

Consistency between models ：

A set of models is consistent with respect to a consistency concept if the models fulfill the syntactic consistency conditions and the semantics of the models fulfills the semantic consistency conditions of the consistency concept.

模型一致性：如果一组模型符合语法一致性条件并且其语义符合某种一致性概念下的语义一致性条件，则这组模型对于这种一致性概念是一致的。

简单的理解：如果一组模型符合某种语法和语义的规则，则认为它们对于这组规则是一致的，也就是规则是成立的。最简单的语法一致性规则是， UML 类图的构建规则，例如类可以包含属性，但是属性不能包含类。如果一个 UML 模型中属性包含了类，则此模型不是良构的，破坏了 UML 语法一致性规则。

Reconciliation ：

Reconciliation is the process of making inconsistent models consistent according to a consistency concept and the intent and expectation of the user. Depending on its requirements, the reconciliation process may run automatically or interactively.

消解（冲突消解）：消解是一种过程，其目的是为了将不一致的模型根据一致性概念和用户的决定和希望重新变为一致。根据其要求的不同，消解过程可以自动运行或者交互的运行。

消解实际上就是模型转换过程，对于一组模型转换规则，如果源模型和目标模型是一致的，则它们符合规则，不需要转换。如果不符合规则，则需要消解 / 转换，通过将它们变为一致的过程（通常是对目标模型进行增、删、改）达到模型转换的目的。消解以后的模型则具有了一致性。

这种方法在 MTF （ IBM 的模型转换工具）中实现了。

Running Example

第二部分给出了一个模型转换的实例如下：

然后给出了一个关系型的模型转换代码（可以看出，这就是 MTF 的代码）：

当然，文中给出的代码是不完整的，可能作者不想牵扯到太多 MTF 的细节，毕竟这是一个博士开题报告，在没有对所有的关系型模型转换语言进行分析之前，就使用 MTF ，也是不恰当的。因此他还给出了基于一阶逻辑的转换定义：

一阶逻辑用来表示模型转换的语义是足够的， OCL 语言其实是一阶逻辑的另一种表现形式，所以有一些研究者将 OCL 做为模型转换语言。其实一阶逻辑看起来还是很清爽的，比具体的模型转换代码更好理解。

Related Work

相关工作包括 MDA 、业务过程集成与自动化（ Business Process Integration and Automation ）、形式化语言的语法和语义、数据库修订理论（ Database Revision Theory ）

其中业务过程集成与自动化不太了解，数据库修订理论是和人工智能领域相关的，也不太理解。

State of the Art

这一节介绍目前模型转换的研究现状。一共有三点内容：第一介绍了模型转换技术出现的动机；第二部分介绍了模型转换技术的分类，分类方法来自 [2] ；第三部分介绍了目前的关系型模型转换方法，其中最著名的是 [3] ，他第一次使用集合论中的关系来表示元模型间的转换规则。

Open Questions and Tasks

这是本文最有意义的一节了，其中介绍了关系型模型转换语言形式化领域中的两个 open question 。

1. The syntax and semantics of the expression language that is used to formulate the set comprehension predicate has to be defined and its logical properties have to be proved. As one single language will not be sufficient for the several use cases for transformations, several languages which map to distinct logical classes have to be investigated.

用来阐明集合理解断言（ set comprehension predicate ，用来表达模型转换规则的关系往往使用集合理解断言来定义）的语言的语法和语义必须被定义好，它的逻辑属性也必须验证。因为单一的语言不足以表达模型转换中的各种使用案例，所以必须研究多种语言，它们分别映射到不同的逻辑类型。

总的来说，作者希望通过研究不同的语言来找到适合描述模型转换规则的关系型语言，或者自己定义这种语言的语法和语义。这些语言都应该是基于某种逻辑的。

2. An execution semantics needs to be defined for relations in the model transformation context. The semantics needs to support two mechanisms:

(a) Two or more models have to be checked for consistency, i.e., that they form a valid tuple with respect to a relation that was defined on them.

(b) Reconciliation has to be supported to be able to ”repair” models that are inconsistent with respect to a relation.

在模型转换环境中，必须定义关系的可执行语义。这种语义必须支持以下两种机制：

(a)    两个或者更多的模型必须能够进行一致性检查。例如，根据定义在它们之上的一个关系来检查他们是否构成了一个有效的组合。

(b)    如果模型不符合一个关系定义的一致性，则必须有一个消解机制来“修复”模型。

作者希望能够定义一个基于关系的可执行语义，这个语义有两种功能：一是检查模型之间是否能够保持一致性，这里的一致性使用关系来定义，即用关系定义的模型转换规则；二是当模型不一致时，是否可以使用消解机制来修复模型从而重新达到一致。这里的消解机制相当于模型转换的执行机制。而消解的过程就是模型转换的执行过程。

理想的关系型模型转换语言的重要特征

在这一节作者还列举了关系型模型转换语言应该具有的某些重要特征，主要包括：

Termination （可停机性）：模型转换方法应该保证是可以停机的，不能包含死循环等。

Confluence （汇合？）：关系的执行顺序是否对模型转换的结果造成影响？在关系之间是否存在着显式、隐式的控制流？两个关系的域并行执行并且有交集时，是否会导致问题？

一般的关系型模型转换语言的执行顺序是隐式的被定义的，例如 MTF ，它从第一个可以执行的 relate 语句开始，然后在语句中调用其它子语句。在 QVT 草案 [4] 中， Relation 语言将所有的 top Relation 语句依次执行，然后在语句中调用其它子语句。而在其它的一些模型转换语言中例如 ATL ，则类似于一般的面向对象语言，是显式定义执行顺序的。

Composition （组合）：将关系组合起来时是否会导致问题？当然，由于关系是描述性的，所以它是没有副作用的，因此组合关系应当是没有问题的。但是这一点如何证明？

OCL 也是描述性的语言，它最大的特点就是无副作用，并且它的计算都被认为是原子的，不存在并行和多线程等问题。但是如何证明关系的组合不会带来副作用还真是没有人想过。

Correctness / Decidability （正确性 / 可判定性）：如何处理转换规范中可能存在的矛盾。集合理解断言可能会含有一些矛盾，它们应该可以被静态的检测出来。

Multi-Directionality （多向性）：转换是否能够被双向的执行，并且不丢失信息。双向转换要求关系必须是一个双射（ bijective ），对于某个语言，一个关系的双射性质能否静态的计算出来？

In-Place Transformations （内置转换（这个词是我发明的，哈哈！））：内置转换能否使用数学关系的方式表达出来？它可能会需要一个状态的概念，一个关系型语言如何支持这种状态的概念？

内置转换也被称为模型进化，意思就是源模型与目标模型是同一个模型。当执行这种转换时显然要复杂一些，因为规则执行的时候是互相影响的，当某一条规则执行时，也许破坏了前面规则定义的一致性。所以可能会需要一个状态来描述模型元素或者规则的执行情况。目前内置转换的研究不多。

Usability （可用性）：一个模型转换语言是否能够适应多种不同类型的转换？即使是很简单的转换规则，使用关系来表述也许是冗长的。语言能否提供一些语法上的简化机制？

目前看来，全部符合以上七点的关系型模型转换语言还没有出现， QVT 的规范 [4] 已经出台，我认为它解决了 Confluence 、 Composition 、 Correctness/Decidability 、 Muti-Directionality 和 Usability 。没有涉及到 Termination 和 In-Place Transformations 。另外，它也没有对这些性质做相关的证明。

总结

这篇文章的最大贡献就是提出了那两个 open question 。并进行了相关的分析。提炼如下：

第一个问题是：如何定义或者选择一个适于表达模型转换规则的关系型语言？它是以某种形式化逻辑做为基础的，并且具有上述的七个特性。

第二个问题是：如果定义这种关系型模型转换语言的执行语义？这里分为两个子问题，第一是如何检测模型之间的不一致性；第二是如何使用消解机制来修复模型。

从去年年底开始使用 EndNote 来管理参考文献了，这个东东真的不错啊。现在随手加参考文献的感觉真是爽！

[1]           Wahler, Michael. Formalizing Relational Model Transformation Approaches. Zurich, 2004

[2]           Krzysztof Czarnecki, Simon Helsen. Classification of Model Transformation Approaches. In: Proceedings of the 18th International Conference, OOPSLA’2003, Workshop on Generative Techniques in the context of Model Driven Architecture. Anaheim, California, USA 2003 

[3]           Kent, David Akehurst and Stuart. A Relational Approach to Defining Transformations in a Metamodel. In: H. Hussmann J.-M. Jézéquel, S. Cook (Eds.). UML 2002 - The Unified Modeling Language 5th International Conference. Dresden, Germany: Springer-Verlag 2002 LNCS 2460.243-258

[4]           OMG, MOF QVT Final Adopted Specification. 2005.

昨天遇到了这样一个xml文档，如下：bookObject.xml

希望能够使用XSLT转换为这样的一个xml文档（目的是为了做一个很简单的模型转换实例，当然这点和本文主题几乎无关）：publicationObject.xml

分析这两个文档可以看出，希望的转换规则如下：

Book节点有一个属性title，它等于Publication的节点属性title。

Book节点包含chapters子节点，每个子节点都有三个属性。其中一个Book节点的所有chapters子节点的nbPages属性相加等于Publication的nbPages属性；

一个Book节点的所有chapters子节点的author相连，并在中间插入and则等于Publication的authors属性。

由于之前我并没有接触过XSLT的变量、参数和xsl:call-template等概念，所以还是颇费了一点时间来解决此问题。

2.     问题的解决

值得注意的有几点：

1.              XSLT中的变量一次赋值后是不能改变的，所以这里的变量几乎等于其它语言中的常量。

2.              template有两种，常见的是通过<xsl:template match="/">这样的方式定义的，使用match属性。调用的时候是使用<xsl:apply-templates select=""/>。另一种template类似与其它语言中的函数调用，使用<xsl:template name=”t_name”>来定义，调用的时候使用<xsl:call-template name=" t_name "/>来调用。

3.              在第二种template的定义中可以加入参数，类似于其它编程语言中的参数列表。在调用时也可以传入具体的值做为实参。

4.              由于XSLT不包含for、while等循环语句。当简单的for-each不能满足要求时。则需要使用递归template调用来完成其它语言中的循环。从functional programming的理论中我们知道这二者是等价的。

下面是进行转换的XSL文档：Book2PubXSLT.xsl

从上面可以看出，解决问题最主要的一点就是使用了一个递归模板concatAuthor，它带有三个参数str，index 和nodenum，分别表示连接的字符串、迭代子和chapters的节点数。通过这种方法，熟悉递归的人可以很快的写出几乎和javascript等价的种种数据操作。当然，由于变量不能赋值、参数只能以递归的方式来改动，还是很不方便的。

其优点也是明显的，不依赖其它脚本语言完成了数据操作。可以在所有xsl引擎上面运行。

3.     小结

深入讲解XSLT的中文文献不多，大多数是入门级的。当我半猜半试的解决了这个问题后。发现了在O’Reilly有一本《XSLT》的书，其中列出了这样的内容。
       哦，今天是女孩节，祝我的乖老婆和乖乖女儿节日快乐，身体健康啦！
既然这么高兴，就贴一张刚刚照的雯雯百日照好了。

MDA提出已经有5,6年的历史了，其主要标准还是MOF，UML（包括OCL），XMI和CWM四大核心。目前正在制订的标准还有QVT（即模型的查询、视图和转换）。这些标准族之间相互关联共同组成了MDA这个庞大的体系结构。可以说，MDA是由系列的标准族加上模型驱动开发的思想共同组成的。而后续的研究者根据自己的兴趣又有了不同的侧重点，导致了MDA阵营的分裂（划分？）。

四个阵营

Steve Cook将MDA研究者划分为三个阵营，Martin Flower也同意他的观点，并针对这三个阵营对待Language workbench的态度进行了详细的讨论。另外，Martin还提出了一个MDD阵营。总结他们两个人的意见，可以将MDA阵营划分为四个部分，其中有的阵营是完全对立的，而有的则是兼容并蓄的：

1.         UML PIM阵营：使用UML来建立PIM，然后利用模型转换来生成PSM，最后用PSM生成代码；

2.         MOF阵营：不使用UML，而用MOF来代替，建模语言和模型转换都使用MOF来定义；

3.         可执行的UML阵营：建立UML编译器，将UML直接作为编程语言，使UML可以执行。

（以上来自于Steve Cook的blog，原文如下：

1. The UML PIM camp: MDA involves the use of UML to build Platform Independent Models (PIMs) which are transformed into Platform Specific Models (PSMs) from which code is generated.

2. The MOF camp: MDA does not involve the use of UML, but instead the crucial technology is MOF, and the definition of modelling languages and language transformations using MOF.

3. The Executable UML camp: MDA involves building a UML compiler, making it a first class programming language.

）

4.         MDD（Model Driven Development）阵营：他们也可以说不属于MDA的阵营，因为他们并不关心OMG的MDA系列规范。他们关注的是模型驱动的开发思想，可以说，MDA就是MDD在OMG规范上面的实现。

也有部分研究者将MDA划分为狭义和广义的两个阵营。同上面的联系起来看，狭义的MDA即前三个阵营，而广义的MDA即MDD阵营。我是这么认为的。

UML PIM阵营

UML PIM阵营可以说是目前最强大的，因为它是如此符合MDA最初的构想，从大家了解最多的UML开始建立PIM，然后转换为PSM（例如CORBA，J2EE，.NET），然后生成代码，一切看来都如此流畅，和以前出现的技术可以兼容，并且也不缺少工具和厂商的支持。

但是，它也是受到诟病最多的一个阵营，一个最大的问题就是关于UML是否是平台无关的问题，如果UML不是平台无关的，则显然它不适合用来构建PIM。MOF阵营的人对于UML的抛弃就是基于这个原因，他们认为MOF才是MDA的本源，过多的使用UML会导致不能真正的构建PIM，因为UML本身就是一个平台。我觉得关于平台无关的争论可以休矣，当初C也是被认为平台无关的，只要在不同的操作系统上重新编译一次即可；后来的CORBA也号称一举解决了网络平台不兼容的问题；再来就是J2EE。可是，当你解决了上一个平台相关问题时，你所创建的新技术同时变成了一个新的平台，如CORBA平台，J2EE平台等。为了解决不同的CPU硬件平台不兼容，发明了操作系统；为了解决不同的操作系统问题，发明了高级语言；为了解决网络不兼容问题，发明了中间件；为了解决中间件不兼容的问题，发明了MDA和web service等等技术。目前看来，使用UML来建立的模型基本上具有平台无关性，我（我是属于UML PIM阵营的）认为使用UML来建立PIM是合适的。

UML PIM阵营的另一个问题是，UML过于繁琐，UML2.0标准充斥着各种各样作用不大的填充物，不仅没有能够让UML更加实用，反而导致了UML的复杂度增加，可用性下降。就好比要使用一个锤子，但是UML给出了一整个房间的工具，在里面翻了半天却没有找到一把合适的锤子。唉。。。因此MOF阵营的人就决定自己去造一把锤子，反正它和UML一样，都贴有OMG出品的标签。

当目前的UML不能完全满足需要时，UML给出了标准的扩充机制，也就是Profile（包括Stereotype和tagged value）。但是，很多人认为UML的扩充机制和UML自身一样，过于复杂，还不如用MOF重新构建一个建模语言（我倒不这么认为，感觉Profile还是比较简单的）。

还有一个不能回避的问题是，UML PIM阵营更加注重系统的结构，而不注重（不能解决）系统的语义（动作/流程），因此很多人倾向于去掉UML动作语义，或者根本不使用UML动作语义。

尽管UML PIM有这么多的缺点，但是其优点也是显而易见的：1.符合标准；2.对于普通的软件从业者来说，学习UML比学习MOF要更容易一些；3.可以使用的工具更丰富一些。

MOF阵营

使用MOF来直接构建建模语言和模型转换语言在一些书中称为“重量级”方法，而使用UML Profile来扩充UML生成新的建模语言称为“轻量级”方法。由此可见，学习和使用MOF是一件比较耗时的事情，但是这并没有阻挡MOF阵营的脚步，他们认为MOF才是MDA的核心，才是纯粹的MDA。

MOF定义的四层模型，几乎将以往的模型概念一网打尽，在前人的基础上（M1层和M2层的模糊概念）又定义了M3和M0层。其中M2层可以包容以往所有已知的建模语言规范，然后定义了一个唯一的M3层，可以创建出所有这些建模语言，目前所有已知的模型技术中，唯有MOF是拥有M3层的，而且它是自定义的。这样MOF兼容并蓄了所有的建模技术，成为一支独大的元元模型工具。目前几乎所有的建模工具都号称MOF兼容的，因为做到这一点实在是太容易了，只要稍微修改一下自己的模型规范即可。可以这样认为，所有不愿意使用UML的建模者，在MDA出现后一定倒向了MOF阵营。而且，新的模型语言和DSL的创建和使用者，也大部分会倒向MOF（使用UML Profile对于这些人来说，不如使用MOF来得顺手和自如）。

OMG在制订MDA之初很明智的让MOF脱离了UML，这样增加了MDA的生命力，与其让MDA技术与新的技术竞争，不如将MDA分化为几个阵营之争。MOF的缺点是学习困难，工具较少，而优点则是灵活自如。由于对MOF没有深入研究过，姑妄言之。

可执行的UML阵营

这个阵营的人一定不会介意我将UML称为第四代语言。在第三代语言（高级语言）瓜熟蒂落之时，就开始了第四代语言的争论，到底第四代是属于SQL这样的描述性语言，还是类似于Agent系统这样的智能系统，或者网格？神经系统？Web Service？但是这个阵营的人会自豪的告诉你，第四代语言就属于可执行的UML，其他的无论影响力还是问题域的覆盖性，统统不如。（可能我的语言有点偏激，大家不要砸砖。。。）

这个阵营里面的人有个很好听的名字，“模型程序员”。当UML真正可以执行了，对于高级语言程序员的需求量就会像现在的汇编程序员一样稀少了。（写到这里，想起了前年和几个网友一起为MDACHINA论坛的《模型程序员》写稿的日子，时光荏苒啊，转眼都当爸爸了。）可执行的UML也是MDA研究的热点，尤其是在MDA技术提出之初，所有的MDAer都满心欢喜的想象UML编译器的出现，可以将手头的模型直接转换为可执行程序。在OMG网站内部，就介绍了三本可执行UML的书籍。

当然，在可以预计的将来（2,3年内？），我都想象不到可以有完全不产生高级语言代码的UML编译器。也许在某个局部领域内可以实现，但是能够做到像高级语言编译器那样完整，在目前是根本不可能的。原因很简单，目前的UML表达能力有限，它不能完全承载程序所需要的信息。即使是UML扩充了动作语义之后。

那么，通过进一步的扩充UML有没有可能呢？当然是可能的！当初谁也不认为高级语言可以完全取代汇编，可是现在已经很少有人再用汇编了（特殊领域如驱动程序等除外）。但是，目前的一个困境就是，UML已经过于臃肿了，已经由于体积的庞大遭到很多人的抛弃，如果再进一步扩充UML，是否会更加引起众人的反感？

对于这种困境，我建议将UML分为两个部分：UML前台和UML后台。前台是在目前UML的基础上进行精简，使之更加易学和实用；而后台是为了定义UML编译器，可以加入更多语义方面的东西。这样，可执行UML阵营的人可以致力于定义UML后台，使之能够完全承载目前高级语言所能表达的语义，从而使UML的执行成为可能。类似于java虚拟机，UML虚拟机也是可能出现的，在这个虚拟机上面，用UML前台编写的模型可以自动运行，如果在前台中没有定义详细的细节，那么后台可以加上大量的默认值使其可以运行。

MDD阵营

MDD阵营严格说来不一定属于MDA阵营，因为他们无视MDA的诸多规范，而是自成一体。他们是典型的“拿来主义”者，有用的就拿来，没用的就扔掉。很多人号称MDA的支持者，但是从来没有遵循过任何MDA的规范。他们只是拿来了模型驱动的思想来武装自己的开发方法。不过他们也许更加清晰的认识到MDA的精髓，毕竟他们还没有在冗长的MDA规范中泡得发白。

从另一个方面来说，他们是更加纯粹的MDA支持者，因为MDA Guide的开头就说：MDA is an approach to system development, which increases the power of models in that work. It is model-driven because it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. MDA是一种方法，而不是仅仅是规范。

小结

谨以此文，献给那些还在MDA泥潭中挣扎的战友们，愿能抛砖引玉。很多地方都是我猜测的，不一定完全属实，如果需要在正规文献中引用，请参阅超链中的正规文献（我链接的很多也不是正规文献，汗！都是blog），或者参阅其他文档。

标题：

Model Transformation and Weaving in the AMMA Platform

地址：

http://www.sciences.univ-nantes.fr/lina/atl/www/papers/CR_2005_GTTSE_transfo_weaving.pdf

时间：

2005

阅读时间：

2005.12.10

摘要：

Model transformation creates a set of target models from a set of source models. This operation is central in current MDE approaches. However, we highlight in this paper some of its limitations. Model weaving is another operation on models, which specifies typed links between model elements. Model weaving can thus be used to specify abstract model transformations assets of links between source and target metamodel types. Therefore, we propose to combine model transformation and model weaving in order to overcome some of current model transformation limitations. This paper presents how we experimented this with ATLAS Transformation Language (ATL) and AMW (ATLAS Model Weaver) on an example.

模型转换从一组源模型创建出一组目标模型。这种操作是目前MDE方法的主流。然而，在本文中我们指出了它的一些局限。模型编织是另外一种模型操作的方法，它定义了模型元素之间的有类型的连接。因此模型编织能够被用于将抽象的模型转换定义为一组源和目标元模型类型的连接。因此，我们建议将模型转换和模型编织组合起来去克服一些当前的模型转换的局限。本文给出了一个在ATLAS模型转换语言和AMW（ATLAS模型编织器）上实践本方法

的例子。

大意：

本文分为六个大的部分：

1 Introduction

当前的模型驱动工程学（MDD）中，例如微软的软件工厂，OMG的MDA等，模型转换都是一个核心的技术。目前已经发展出很多模型转换的方法，但是模型转换的标准QVT一直没有能够制订。模型编织是另外一种操作模型的方法，它通过建立模型元素之间的连接来编织模型。模型编织与模型转换存在一些不同之处。它克服了模型转换的三个主要局限。

2 Transforming Relational Tuples into an XML Document

本节介绍了一个应用场景，在一个图书馆信息系统中，将RDBMS的数据转换到XML文档中。其各自的元模型如下：

在这个场景中，使用ATL语言定义了一个模型转换程序，如下：

module RDBMS2XML;

create Target : XML from Source : RDBMS;

rule Books {

from

db : RDBMS!BookRcd

to

xml : XML!Book (

Title <- db.Title, Author <- db.Author,

ISBN <- db.ISBN,

subjects <- RDBMS!SubjectRcd.

allInstances()->select (e | e.SID = db.SID)

)

}

rule Subjects {

from

db : RDBMS!SubjectRcd (RDBMS!BookRCD.

allInstances()->exists(e | e.SID = db.SID))

to

xml : XML!Subject (

SubjectID <- db.SID,

Descr <- db.Name

)

}

这个程序定义了如何将RDBMS的模型转换为XML模型。

3 Limitations of Direct Transformations

本节详细说明了上面模型转换方法的三个缺点：1)方向性，只能从左到右转换，如果要反向转换则必须再写一个模型转换程序；2)模式重用，对于稍微复杂的转换，要写大量雷同的代码，很多代码具有相同的模式，但是不能直接重用。3)变更的传播性，源和目标模型有小的改变则必须改变程序中的多处代码，很容易出错。

4 Introducing Model Weaving

本节以上面的实例作为例子介绍了模型编织的概念。下图很能说明模型编织的概念：

从上图可以看出，上面的模型编织使用了三种类型的连接，分别是Equals，FK和Nested。其含义显而易见。

另外，文中给出了模型编织的元模型。因为模型编织的实例也是一个模型，因此它需要元模型予以规范。所以，文中给出了这个元模型关系图：

文中还讨论了WMM所应该具有的扩展性等特点，但是没有给出具体的元模型描述。

5 Combining Weaving and Transformation

本节简要介绍了如何将模型编织和模型转换组合起来来解决目前的模型转换中存在的问题。其主要思想是：首先建立一个模型编织的模型，然后利用这个模型来创建一个模型转换的程序，然后利用模型转换程序来具体进行模型转换的执行。

通过模型编织的方法，克服了以前模型转换的三个缺点。

6 Related Work

介绍一些相关工作，主要是模型转换的一些方法。

7 Conclusion

结论也是老生常谈，再把上面的工作和优点都复述一遍，最后还说明了模型编织还可用于更加复杂的场景：在UML Profile和DSL之间作桥接。

感想：

模型编织

Model Weaving这个概念我是第一次见到。本文正好是一篇Model Weaving的入门文章，极大的满足了我的好奇心。Model Weaving的中文译名还不知道有没有正式确定，和MDA群里面的人讨论了一下，原来大家都翻译为模型编织，看来我还是误打误中了。

新生的事物总是缺点与优点同样突出的，模型转换方法发展好几年了，但是其最显著的缺点还是没有大的进步。本文指出了三个缺点：双向的模型转换方法很少而且难以实现；模型转换程序的代码难以重用；变更传播。

很多研究者希望通过制订新的模型转换语言或者增加其语义来解决这些问题。但是本文的作者境界更高一点，他提出的模型编织是从一个更高的层次来解决问题，即提出一个模型转换程序生成器，来生成已有的模型转换程序，来降低模型转换程序的编写复杂性。所谓的模型编织即用一个二元连接来连接两个模型元素，并对这些连接制订类型和约束，最后根据这些连接类型来生成简单的模型转换代码程序块。这样一举解决了上面的三个问题。其思想含义等同于C编译器将C程序编译为汇编代码。

作者使用的模型转换语言是ATL，使用的模型编织器是AMW，他们统一集成在一个AMMA平台中，这个平台目前是一个开源的Eclipse插件。由于我还缺乏足够的资料，目前不能确定作者是否就是这个AMMA平台的开发者。

模型转换语言

模型转换是MDA的热点所在，目前模型转换方法提出了很多，但是具体的模型转换语言我也只接触了三种（精力所限啊）：

MTF，模型转换框架，IBM定义的模型转换语言，Eclipse插件，规则型的模型转换语言，用来转换基于Eclipse的模型插件定义的模型很方便；

ATL，本文介绍的模型转换语言，我还没有具体使用过，从本文的例子程序来看，也是规则型的模型转换语言。同MTF相比，ATL详细定义了什么是源模型，怎样创建目标模型，这样可执行的程度更强，但是就只能单向执行，并且也相对复杂一些；

OCL，OCL用来定义模型转换其实是水到渠成的一件事情，但是目前还不确定是否有可以运行的基于OCL的模型转换语言。ATL中就使用了部分的OCL。

问题解决了么

当年在高中我学完经典力学时，认为所有问题都解决了，因为它是如此完美，上帝规定了所有的定律并创造了整个世界，然后用手轻轻一拨，世界便沿着宿命的轨迹运行到毁灭为止。后来才知道，有一种思想就叫宿命论。例如，我今晚选择写blog而不是去看网络小说，是因为我的某些脑细胞收到了某些脑电流刺激，而这些都是一些物理定律决定的，因此当世界开始的时候，就注定了我今晚要写blog。Hoho！后来才知道有什么概率问题，测不准原理等等上帝掷骰子的动作。

事实上，所有问题都没有解决的一天，直到这个问题不再成为一个问题，没有人再关注它是否解决为止。

模型编织是否能够解决模型转换中存在的问题呢？当然不能，它只是在某个方向上作了很好的探索而已，事实上，它并没有触及到模型转换问题的本质所在。如我所言，模型编织事实上是一种模型转换程序产生器，无论多么优秀，但是模型转换程序本身不能解决的问题，它一样不能解决。充其量它减少了一部分复杂性，多了一些可用性而已。

模型转换是为了解决模型之间的自动转换问题，或者说是为了自动生成软件模型；软件模型是为了解决高级语言代码的自动生成问题；高级语言是为了自动生成汇编语言。。。现在我们可以在模型转换上面再加一层了，可否就称之为模型编织层？记不得在哪篇文章中看见过：当某个问题无法解决时，我们就在软件中再加一层来折衷。我们到底是在写软件还是在做千层饼？

方法多了一种，路多了一条，但是问题依然存在。

题外话

我的blog又是两个多月没有更新了，这是有原因的（废话!不算）。前一个月我在努力写一篇论文，期间又去南京参加了一个会议。后一个月在家陪老婆生娃娃，努力喂奶换尿布做好爸爸，以至于累出胃病。不过成果是喜人的，特贴出小宝宝9天照，以资鼓励：

Extending UML To Visualize Design Patterns In Class Diagrams

原文链接如下：

http://www.utdallas.edu/~jdong/papers/seke03.pdf

2          时间：

2003以后

3          阅读时间：

2005.8.29

4          摘要：

一个设计模式描述了对于某个设计问题的一种通用解决方案，并可以在多个项目中重复使用。软件设计师会在具体的项目中采用这些设计模式。设计模式通常使用UML建模。但是，当某个设计模式被应用于或者结合了其他模式时，UML不能保存与设计模式相关的信息。因此，设计者很难从软件系统的设计图中识别出设计模式。设计模式的好处被削弱了，因为设计者不能以他们自己使用的设计模式、设计决断和设计折衷的方式来进行交流。本文中，我们提出了UML语言家族的一个新成员的一组本质特征，它支持在面向对象的设计模式上工作。这个UML扩展允许在软件设计中进行设计模式的直接表达。我们也讨论了基于标准UML扩展机制的UML Profile的一些相关的方面。文中的一个示例展示了它如何被用于辅助基于模式的软件开发。

5          大意：

除了摘要外，文章分为六个部分，分别是介绍（Introduce）、UML扩展机制（UML Extension Mechanisms）、被提出的扩展（The Proposed Extension）、示例学习（Case Study）、相关工作（Related Work）和结论（Conclusion）。

5.1  Introduction

Introduction部分介绍了为什么要对UML做基于设计模式的扩展。首先当然是论述了设计模式的重要性，然后指出了UML对于表达设计模式的不足之处，其中最重要的不足之处就是当有几种设计模式混杂在一起时会导致设计模式相关信息的丢失。这点很容易理解，当某一个类扮演了不同设计模式中的不同角色时，确实不能够只从类的名称上看出设计模式的相关信息。

5.2  UML扩展机制

UML扩展机制这一部分简要的介绍了UML的标准设计模式（UML2.0），包括Stereotype（构造型），Tagged Value（标签值）和Constraint（约束）。

5.3  The Proposed Extension

The Proposed Extension这一部分是本文的重点所在，提出了UML Profile for Design Pattern。这个Profile包括三个Stereotype和三个Tagged Value，以及一些约束，具体内容如下：

Stereotype表

Tagged Values表

简单的说，这个Profile里面增加了三个Stereotype，分别是PatternClass、PatternAttribute和PatternOperation，它们分别扩展了UML中的元模型元素Class、Attribute和Operation，其含义分别代表了设计模式中的类、属性和操作等角色。另外对于每个Stereotype，还附加了一个标签值，标签值的形式是<name[instance],role>，其中name代表设计模式的名称、instance代表设计模式的实例标号（例如有两个Abstract Factory模式，则编号分别为1，2）、role代表设计模式中的角色名称。最后还有两个用OCL写成的约束。

对于某一个模型元素（例如类、属性和操作）扮演了多个设计模式中的不同角色的问题，可以将多个标签值按次序写在Stereotype的后面，来显示这个元素的多重身份。例如<<PatternClass{<DAO,DataAccessObject><Abstract Factory[1],AbstractFactory>}>>这是DAO这个类的构造型，它显示了DAO这个类属于两个设计模式，第一个是DAO这个设计模式，其中的角色是DataAccessObject（数据访问对象）；第二个是抽象工厂设计模式，其角色是AbstractFactory。

5.4  示例学习

这一部分展示了一个使用了UML Profile for Design Pattern的小例子，这个例子是一个“学生信息管理系统”，其中使用了两个抽象工厂模式，两个单件（Singleton）模式，一个DAO（数据访问对象）模式。其设计图如下：

（算了，设计图太大，还是到原文中去看吧。原文是pdf，看得比较清楚！）

5.5  相关工作和结论

这两个部分当然是说本文的工作好，比起其他相关工作来有优点。

6          笔记：

感受最深的是，这篇文章提出了一个很正式的UML Profile for Design Pattern，而且这个Profile简单实用，比起其他连篇累牍的Profile来，本文提出的解决方案确实有可行之处。

第二点是这篇文章的作者考虑到了多个Pattern在一起容易混淆角色的问题，并做出了完整的解决方案，使用了多个标签值来避免了信息的混乱和遗漏，这一点也加深了我对于标签值功能的印象。

第三点是这篇文章中的示例非常优秀，是一个很常见的例子，其主要思想是在数据库变更的情况下，如何保持原有代码不变动。其中用到了抽象工厂和DAO这两个非常成熟而优秀的设计模式，加深了读者对文章的理解和印象。

总而言之，这是一篇非常值得借鉴的文章，它对于有以下读者都很有帮助：

1.         正在学习UML扩展机制的人；

2.         正在学习设计模式使用的人；

3.         正在研究MDA的人；

4.         正在研究模型转换、模型重构、模型进化这一类问题的人；

这篇文章我觉得非常优秀，并不是它的理论多么高深（事实上几乎没有什么理论），也并不是它的工作量多么大（可以看出工作量很少），也并不是它的作者多么有名（反正我第一次看见这两个作者），而是它确实对某个有意义的问题做出了接近与正确的解答。正是因为看到了这篇文章，让我对自己刚刚写好的一篇文章进行大刀阔斧的修改，在文中完全使用这篇文章所提出的UML Profile，如果有人看到了更好的UML Profile for Design Pattern，请通知我一声，谢谢！

7          后记

我的博客又好久没有更新了，这与我刚刚过去的暑假有直接的联系，不是我懒惰，而是暑假太诱人，如果我还有暑假的话，我保证在下一个暑假一定会更新我的博客。

在omg的UML2.0规范文档《UML 2.0 Infrastructure Final Adopted Specifcation》中，第183页掉了两个括号，第一个是在下面的OCL表达式中：

self.metaclassReference.importedElement->

select(c | c.oclIsKindOf(Classifier) and

(c.generalization.namespace = self or

(c.specialization.namespace = self) )->isEmpty()

很显然子表达式(c.generalization.namespace = self掉了一个反括号“)”。

另外一个错误也是在一个OCL表达式中：

self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())->

union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty()

这次掉了一个正括号“（”，位置是整个表达式的开头。

由此可见，OMG的打字员很不喜欢括号。嘿嘿！

由于颇为无聊，则给OMG发了一封Email，结果163的邮件在1秒钟后就被退了回来，由此可见，OMG很不喜欢网易！改用Gmail，则很轻松的发出去了。这说明，OMG和Google关系很好。但是上次一个同学说，用Gmail给一些国内的邮箱发信，则会经常被退，看来无论如何，蛋糕是分不均的。为了保险起见，还是国内国外的邮箱各一个最为保险。

说到邮箱，上次我的163邮箱被盗了，不知道哪位大虾干的，我好不容易才拿回来。希望大家不要再盗我的邮箱了，没什么意思，里面绝对没有sex相关的内容，都是一些技术相关的联系邮件，于你无益，于我却损失颇大。况且，我不是研究网络安全的，也无意与你切磋相关技术，如果真的要显示自己是黑客高手，请去盗一些国内著名黑客的邮箱吧，那样会让你一举成名。

酷暑炎炎，无心睡眠，研究UML Profile，颇有心得，乃记之！

        今天我会告诉大家怎么样更加方便、容易地来开发软件。为什么大家都觉得软件开发非常困难呢？我觉得主要原因是业务领域跟计算机领域之间的概念有很大的差别。一般来说业务是用自然的语言来表述，但是软件有可能是用一些非常低级的计算机语言来表述的。构建一个软件需要写很多的代码，要写很多的控制逻辑，有很多复杂的东西在里面。作为软件开发者我们的任务就是要在业务跟软件之间构建起一座桥梁。我们有四种方法使得软件开发变得更加简便。

         第一种方法就是尽量向业务领域描述靠拢，尽量用高级语言来直接描述业务领域的概念。大家看到右面这张图是用高级语言、抽象语言来描述的业务的概念，从业务模型到最终软件的实现有可能还要构建一些中间的层次来搭建他们之间的桥梁。为了控制细节上的复杂度，就要很好地来构建我们软件的架构，控制好构件之间的协作关系。为了减少我们书写的代码量，我们可能会使用一些自动化的工具来帮助我们自动生成代码。大家都习惯于最简单的软件开发方式就是坐下来直接写代码，这看上去好像是一种最简单的方式，但实际上最后会给我们带来更大的麻烦。如果开发人员只是写代码而没有设计的话，很有可能他所构建的这个系统的架构就不是那么完善，同时代码之间没有很好地协调。不同的开发小组写的代码可能功能上会有所重叠或者是相互冲突，不同的开发小组就会使用不同的、不一致的格式进行交互。这是一种非常不好的协作模式，因为开发团队之间会相互干扰，而破坏对方的一些工作成果。而且如果是开发人员去写代码的话，就意味着他们有更多的工作要去完成。在最糟糕的情况下大家看到这样的系统有可能是非常脆弱的，任何改变都可能会破坏整个结构。

         我们向大家推荐的方法就是称之为模型驱动架构这种新的方(MDAModel Driven Architecture)。在这种方法里我们使用一个高级的模型来描述一些业务领域的概念，基于这种高级的模型再来生成基于某种特定运行平台的代码。在这个过程中我们会使用一些自动化的工具，基于一些标准来生成我们的代码。MDA方法是由对象管理组OMG (Object Management Group) 提出来的，OMG是国际化的标准化的组织。我们在开发的时候，起点是比较高级的业务领域的模型，这个模型我们称之为平台无关模型，也就是PIM (Platform Independent Platform)。在这个平台无关的模型里我们着重关注的是业务的逻辑。涉及到具体平台相关时我们会使用一种与实现相关的Profile，这种Profile描述了特定平台的实现细节。基于平台无关的模型以及特定平台的Profile就可以自动生成基于某种特定运行平台可运行的系统，称之为平台相关模型PSM (Platform Specific Model)。从同一种平台无关模型出发，你可以针对多个不同的运行平台来生成多个不同的PSM，最后基于PSM你还可以生成具体的代码。在MDA里我们需要三样东西，首先我们需要来描述问题的模型，在这里可以使用UML或者是使用新的领域描述语言DSL (Domain Specific Language) 来描述业务领域方面的模型；第二个需要利用架构框架来描述具体的实现，架构框架可以针对某种具体实现作出一些假设，从而基于这些假设来减少我们在建模阶段所涉及的细节，最后通过一些自动化的工具来生成实际可运行的模型或者是模型的特定翻译工具等等。

         接下来我要介绍的是问题领域相关的模型。一种描述问题领域模型的方式就是使用UML，大家都知道UML最初是由Grady Booch、Ivar Jacobson和我共同创建的，后来OMG里的其他成员也陆续对这个语言进行了扩展。现UML已经成为对象领域被全世界开发人员广为使用的一种语言。跟编程语言相比UML是一种更加高级的描述语言，在这种语言里我们减少了很多不必要的、细节的描述。理论上讲UML可以应用于很多领域，我们可以对UML加以改造，利用一种称之为UML Profile的机制可以使UML用于某些特定的领域。UML Profile是在UML的基础上针对某些特定的领域进行一些改造，使得它能够支持这些业务领域里特定的业务概念。但即便是我们使用UML Profile这种特殊的机制，UML本身还是一种非常通用的语言，里面还是包含了很多重复性的细节。另外一种方式就是利用称之为领域描述语言的DSL语言来描述问题领域的这些概念。DSL是一种特殊的语言，有它自己的语法和语意，它是针对某一种业务领域而设计的。DSL是利用一些比较高级的概念来描述问题领域的概念，这样它可以减少业务领域跟具体实现之间的差距。DSL里也可以包括一些预先置好的数据与模式，基于DSL的模型可以减少一些重复性的控制逻辑的描述，同时生成更加底层、详细的代码。这里我们来看一些现有的DSL的例子。

         首先大家想不到的是在30年以前我们就有这样一种DSL语言，就yacc，在这个yacc里用巴柯斯范式BNF来构建编译器。yacc编译器就可以利用你所描述的BNF来构建复杂的语法编译工具，从而减少手工开发这种编译工具的难度。另外一种大家想象不到的DSL是大家经常用的GUI编程工具，来帮助你搭建用户界面。在这种工具里就可以在屏幕上画上你想要的表格、图表或者是控件等等。大家看到在屏幕上画了这些控件，在内部代表着上千行的代码。但是开发人员不用去描述这些细节的控制逻辑，工具会帮你做到所有的这一切，这样大大简化了开发人员的工作量。另外一种DSL大家可能都想像不到，就是我们日常在使用的桌面编辑工具，像FrameMaker 或者是Word工具。作者可以很容易地用这个工具来写下他们所编辑的书或者是插入一些他们想要的控制逻辑，像图片等等。另外一种就是大家知道的MIDI，用于在乐器跟电脑之间的一种描述语言，它可以让电脑也能够产生音乐。音乐家利用MIDI这种语言不用编程就可以创造出音乐。另外一个例子就是数学上的一些应用工具，利用这些工具用户可以直接用数学表达式、数学公式来描述一些复杂的概念。

         这里我再给大家介绍另外一种特殊的DSL，就是以前大家广为使用的SDL。SDL是国际电信联盟ITU所通过的一种标准，很多电信制造商都在利用这种标准来描述他们的电信设备，如交换机。很多知名的电信企业如摩托罗拉、爱立信等都在使用SDL来描述他们的应用。这种语言提供了复杂的描述手段，使得这些企业能够利用它来描述电信上的一些复杂协议。我跟这些企业的开发人员都有过一些合作，我发现他们在使用一些工具时都存在着一些困难。因为随着时代的进步SDL逐渐退出了主要的潮流，它并没有包括一些最新的像UML工具里的一些特性。最近对象管理组OMG刚刚完成一项项目，就是把UML升级到UML2.0。来自于摩托罗拉、爱立信的开发人员成为这个项目组的成员之一，在这个项目里我们把SDL的一些概念也加入到UML2.0里面。所以当UML2.0出来之后现在可以把SDL做成UML的一种Profile。这意味着传统的SDL的用户也可以利用UML工具来继续你的软件开发，同时也可以利用UML里其他的一些特性。这也是一个很好的DSL语言的发展历程，在这个历程中大家看到如果一种概念型的领域描述语言比较有用的话，其实还会继续延伸它的生命力，比如像SDL被加入到UML2.0里去。

         有关这个领域描述语言有几种不同的类型，有一种形式称之为描述式 (Declarative) 的。在这种描述式的语言里只需要描述我们需要做什么，但是并不需要描述详细的控制逻辑。这就像我们用数学公式来描述复杂的数学问题一样，并没有说明我们应该如何来解决这个问题。这种形式的DSL被广为使用，因为简化了开发的工作量，他们并不需要描述详细的控制逻辑。如果计算机能够自动地生成这种解决方案的话，这其实是一个非常有用的方式。但是实际的情况并不是如此，所以会有另外一种形式的DSL语言称之为命令式(Imperative) 的，需要写出一行行的指令来告诉如何解决这个问题。这种形式的DSL详细描述了具体的控制逻辑，当然也给开发人员带来了难度，因为它更难以使用。所以我们想出一种折中的方式把这两种形式结合起来。在这种方式里我们就用一些高级的描述性的方式来描述这些问题领域的概念。在开发的后期我们可以使用低级的命令行的方式来描述这些细化的控制逻辑。这种方式实际上是结合了前面两种描述方式的优点。现在又有了一个非常流行的概念叫做面向Aspect的编程 (AOP – Aspect Oriented Programming) ，在这种方法里我们是把不同的需要解决的问题划分成不同功能的Aspect，一些有关Aspect的例子就包括如何控制安全性、如何永久地保存数据、如何提供一种并发的处理机制、以及如何记录一些日常信息等等。所以每一种Aspect实际上可以帮助我们来解决某一个特定领域的问题，但是这种解决方案是横跨整个系统的。在这种方式里我们需要有一个翻译软件把这些Aspect转化成具体的代码。解释软件应该知道Aspect之间的差异和相互的交互，应该能够补充一些必要的代码把他们整合起来。实际上从本质上讲AOP方法跟刚才讲的DSL语言是非常接近的，在每一种方法里都有一种高级的描述方法来描述问题领域的这些概念，同时都需要有一种翻译软件把这个模型翻译成最终的实现。现有的这些AOP语言并不是太好，有些并没有我们想像中工作得那么好。翻译工具不能很好地工作，开发人员还是需要去描述一些他们之间实现的细节。我认为在AOP这种技术真正非常流行之前，我预期到AOP的下一个版本一定要增强转换 (transform) 的功能，这样才能能使得它更加流行。我认为这种DSL语言可以帮助我们来描述这种AOP 的自动生成、自动转换功能。

  接下来我们来看一下架构框架。架构包括好几样东西，首先在构建架构时要做的是将系统分解成为一些子系统，这些子系统本身应该有完整的功能，同时应该能够相互交互。子系统之间功能上不应该有重叠，在这种架构里我们需要描述子系统之间交互的拓扑逻辑，常见的拓扑逻辑包括像流水线、星形结构等等。架构的另外一个方面就是要描述子系统之间的交互规则以及他们所交换的数据格式。另外架构设计师也需要描述有关资源管理的规则，这样使得不同的开发人员能够更加有效地来使用这些资源，这里提到的资源就包括像内存、系统进程等等这些概念。所谓好的架构跟差的架构之间的差别就在于一个好的架构它能够更好地适应系统将来的变化，注意这个变化是不会自动发生的，是应该由架构设计师为将来的变化做好准备。在一些好的架构里会使用“钩子（Hook）”这种机制，它可以使得我们不用修改这个系统就可以增加一些新的功能。我们经常看到很多项目延期的情况，原因就是项目里的很多测试工作被忽略掉了。举一个类比，大家想想现在汽车里的发动机，发动机里有很多传感器，这样汽车上的电脑可以随时感知发动机里的工作状态。大家想象一下如果先把发动机造出来再把传感器放进去，这实际上是行不通的，在设计发动机时就应该考虑要把传感器放进去。在做开发时架构设计师也要把测试这个概念加入到开发过程中去，使得测试成为我们开发过程的一部分。所以我们应该在早期设计架构的时候就应该考虑到测试，这样能够有效地提高软件的质量。实际上大家都知道架构是很难去搭建的，我们想方设法使得架构这种工作对开发人员来说变得更加简单。所以我们是把其他开发人员在开发过程中得到的一些好的架构经验总结出来，称之为架构框架。所谓的架构框架实际上是一种可重用的架构模式，这种模式是从好的架构模式里总结出来，这些架构模式可以进一步地被其他人所重用。

         架构框架包括好几样东西，首先我指的是执行环境的框架，这里包括很多小的元件，这些元件之间是相互继承的。这些小的控制单元对用户来讲并没有提供它的价值，它所关注的只是这些小的控制单元内部的控制逻辑。它也包括预先定义好的系统之间交互的接口、数据格式等等。所以我们可以预先构建好一个系统，逐渐地往里面增加它的功能。实际上我们很难把所有的东西都组合在一起，一下子把它构成一个可运行的系统。如果你试图把所有的东西一下子都集成起来的话，这实际上是非常困难的。一种比较简单的方法就是你从一个小系统开始，在开发的过程中逐渐往这个系统里增加功能，逐渐地把这个系统建立起来。基于这种开发理念，我们在设计架构框架的时候就会预留好一些扩展点，通过这些扩展点可以增加更多的功能，这些功能有可能体现为一些插件。在构造系统时就是把不同的插件插到不同的系统上去，好的架构框架应该也包括一些可重用的构件。开发人员应该利用现有的构件来开发系统，而不需要写代码。在构建一些复杂系统时，开发人员有可能也需要自己去开发一些构件，但是并不需要所有的构件都从头做起。一切好的架构框架实际上都应该包括一些好的例子，这样对我们可以有更大的帮助。实际上大家都有这种经验，当你采用一种新技术时很难判断怎么样把各种部件集成在一起，但是如果这时有一些很好的例子的话，我们的工作就会变得简单。这里大家看到的一些有关架构框架的例子就包括我们经常谈到的Eclipse、.NET或者是J2EE架构。

         使用架构框架可以给我们带来很多好处，它可以使我们非常容易地利用DSL来描述一些现有的概念，也可以帮助我们来保证系统的一致性。如果系统是由很多小组来开发的话，这种框架可以在不同小组搭建的系统之间保持高度的一致性。另外它也可以保证基于同一种架构框架的不同开发应用也保持高度的一致性。另外它使得用户的界面所使用的数据模式、用户的体验等等在不同的应用之间也保持高度的一致性。架构框架也可以很好地帮助增量式的开发，可以从一个小的系统开始，基于这种框架来逐步增加它的功能。另外架构框架也可以减少我们开发设计的工作量，使得不同的开发人员在设计的时候减少他们的分歧。

         我们有很多种方法来帮助我们描述一个架构框架，第一种方式是可以用UML模型来描述架构框架，可以描述结构模型、接口模型、描述模式等等。基于那种框架我们可以描述DSL语言的语法和语意。每一种架构框架都会包含一些具体的代码，象C++或者是Java等等。每一个框架也应该包含一些文字描述来告诉使用者如何来使用这个框架。总而言之架构框架的基本思想是要从专家手里把一些好的经验总结出来，使得所有人都能够共享这些好的经验。一个类似的例子就是模式 (Pattern) ，模式已经是十年前的一个概念了。模式可以帮助我们来构建架构和解决一些具体的技术问题。什么是模式呢？模式是针对常见问题提供的解决方案。很多模式都有不同的参数，这些参数使得模式可以应用于不同的领域。所谓的模式有很多种级别，有些是比较低级的，象通常我们讲的设计模式，也有一些是帮助我们来构建模型的，也有一些是帮助我们来搭建系统架构的。跟我们刚才提到的架构框架一样，每一个模式它都应该有这样几部分，包括架构、结构、内部的交互规则以及一些使用指南等等。另外一种共享经验的方式就是来构建可重用的构件，构件是为一种特定的架构所设计的，在这个架构下不同的构件可以很好地相互合作。

          接下来我再给大家介绍的是MDA技术中有关自动化工具的部分。我们在做MDA开发时需要的是一个建模工具，这个建模工具可以帮助我们来描述模型以及各种模式。如果你开发的是一个小系统，只有两三个人的小项目，就不需要建模工具。但是即便是简单的问题也有必要来使用工具，例如你会使用计算器来把数据加在一起，这样使你的工作更加简便。对于一些大的项目、十几个人的项目当然需要一个建模工具来帮助你们团队协作、帮助你们来记录你们设计的结果。假如没有工具来协调大家工作的话，在建模过程中你们的工作有可能会相互重叠、相互冲突，有些信息可能会丢失。工具同时也可以帮助我们来找出你设计中的一些错误或者是瓶颈之所在，帮助我们避免一些问题。一个好的自动化工具也可以根据你所指定的特定架构和平台来生成可运行的代码。自动化工具在生成代码时也会生成一些追踪信息，就是从模型到代码之间的关联关系也会被记录下来。对于一些大的项目而言，有可能你们会使用很多种不同的工具，这些工具有可能带来的困难是他们之间很难进行信息的交流。在这种情况下我们需要有一个公共的存储库来存放和管理所有的这些工具所产生的数据。这种公共的存储库应该可以使开发人员自由地修改数据，而并不影响其他人的结果。用于构建这种存储库的技术就包括MOF（Meta-Object Facility元对象设施），另外一个是XML (eXtended Markup Language) 。

          用于MDA开发的另外一种工具主要是翻译工具，可以帮助我们把模型自动地翻译成为代码。一个好的工具可以基于某种特定的平台帮助我们生成代码。另外一种翻译工具就是一些代码优化工具。一个例子是，大家可以把这种优化想像成为它可以把一个简单的代码映射成为复杂的代码，从而提高运行效率。另外的转化工具包括重新排版、组合这些代码等等。实际上一个好的转化工具是很难得到的，现在我们有很多种不同的变换工具，现在对象管理OMG正在进行的一个项目称之为QVT (Query-View-Transformation) 项目，就是查询、察看和变换，这个项目的主要目的是为变换工具制定一个标准。这个项目预定是在明年的第一季度结束，一旦这个标准出台的话，它就可以使得不同的变换工具之间的协作变得更加简单。

  对于这种变换工具我们到底有哪些要求呢？首先这种变换工具一定要理解源和目标语言的语法，同时在这种工具在生成代码时，不要指望它生成的是最好的代码（可能是比较好的代码），因为通过这种工具已经减少了我们很大的工作量。实际上在这种变换工具上已经有很多年经验的积累，比如大家经常用到的编译器，我们希望把编译器上好的经验吸收过来。一方面需要构建自动化的变换工具来帮助我们转换代码，但是同时也要注意到我们现有的项目有很多历史代码。我们希望这种新的QVT标准能够接受插件，以插件的方式来支持现有的这些代码。对于这个变换工具的另外一个要求是要使得它能够维护代码跟模型之间的关联，因为每当你对模型作出一个小的修改时，我们是希望这个工具能够相应地生成变化的代码，而不是每当你修改一部分模型之后这个工具需要把整个模型重新生成一遍，这是非常费时的。为了满足这种要求，变换工具需要保持模型跟代码之间的关联关系。对于这种变换实际上我们有几种不同的方式。第一种就是部分的转换，在这种方式里我们是把模型转换为代码，但是在这种转换里很多实现的细节是被忽略掉的。比如说现在大家正使用的很多UML工具实现的就是这种转换，这种转换只是帮你生成数据结构或者是一些简单的代码框架。所以这种变换方式生成代码非常快，但是开发人员或者是编程人员需要做更多的工作来增加细节的描述。当然在这种变化里存在着风险：如果编程人员修改代码的话，有可能会破坏掉代码跟模型之间的关联。我们称之为双向变换的技术实际上是可能的，只要我们在这种变换工具里，在生成的代码里保持这种代码跟模型之间的关联关系就可以了。所以每当开发人员修改模型的话，我们就知道相应的哪一块代码需要做相应的修改了。但是这种逆向的变换往往是比较模糊的，从代码到模型我们往往不知道怎么样根据代码生成一个什么样的模型。主要的原因是因为代码比模型包含的信息更少，但是这种部分的变换技术其实是比较切实可行的技术，因为我们可以快速地利用它来建立我们的模型，并且生成我们的代码。但是从长远的角度来看这有可能并不是一个很好的解决方案。

          另外一种取而代之的方法是完全生成，在这种技术里我们只有一种单向变换，就是从模型直接变换到代码，而且是百分之百地生成代码。在这种方法里开发人员是不会去修改生成的代码。但是这也对DSL语言提出要求，DSL应该有能力来描述足够的细节。编译器就是一种完全生成的很好例子。大家都有这种经验，只会用编译器生成代码，但是从来不会去修改编译器所生成的汇编代码或者是信息代码。当我在很多年以前开发工作时这并不是一个事实，那个年代人们对编译器还不是非常信任，开发人员经常去检查编译器所生成的代码。现在编译器已经发展得足够成熟、足够好了，所以大家都非常信任这种变换。现在大家用的另外一种完全生成的例子包括格式的转换，比方现在有些工具可以帮助我们从UML模型生成XML格式。完全生成这种技术有可能适用于那些我们能够掌控所有细节的场合下使用。尽管现在这种完全生成的技术不是非常成熟，但是我预期在将来这种技术应该是越来越可用的。

         第三种方式其实是把前面两种方式都结合在一起，就是把代码嵌入到模型中去。在这种方法里开发人员会把代码的片段插入到模型中去。在这种模型里如果DSL的描述能力不够的话，开发人员就会用编程语言来描述这些细节。当变换工具生成代码时就会把开发人员插入的代码嵌入到最后生成的代码中去。所以如果开发人员想修改最终生成的代码的话会修改这个模型中插入的代码片段，重新利用这个模型来生成代码。这种方式有可能更象我们谈到的部分生成的例子，因为在这种技术里开发人员还是需要来写一些编程代码。但是他们还是有不同的，因为在这种技术里我们是把模型跟代码存放在同一个文件里。与其他的技术相比这种方式避免了我们丢失了模型跟代码之间一致性的危险。因为这个变换工具知道插入的代码在模型的什么地方，所以它可以很好地在模型跟生成的代码之间搭建这个映射。实际上这是一种非常灵活的技术，这种技术在几十年以前，在刚才提到的编译器的生成里面就已经用到这种技术了。这是一种非常灵活的工作方式，但是它要求开发人员同时在两个不同的层次进行工作，他既应该在高层次模型这个级别工作，同时也需要开发人员在低层次代码这一级别进行开发工作。但是在当前这个情况下，在我们有更好的完全生成的解决方案之前，这有可能是一种比较实际的技术。最后是一种更加先进的变换技术，在这种变换技术里我们为这种变换本身搭建起一个变换的模型。在这种技术里面，我们会针对这种变换来建立起一个模型，并且利用这个模型把原模型跟目标代码联系起来。利用这种开发技术进行开发的话，就意味着我们通常所讲的设计就是要去构建出这样一个变换。一旦我们搭建起这样一个变换模型就可以把这种变换应用到很多源模型上去。比如说我们可以应用这种技术来构建一些模式，利用这个模式应用到很多领域上去。这是一种非常强大的技术，但是我并不认为这是每一个开发人员都适用的一种技术。这种技术需要一些特定的技能以及相关的知识。但我还是认为这种技术可以给大家带来益处。谁可以用这种技术呢？是一些在开发团队里专门负责构建这个模式或者是构建架构框架的人，有一部分人可以用这种技术来构建出比较好的模式或者是架构框架，使得这种好的经验可以使更多的开发人员受益。

          很多对于建模的批评就集中在模型是不可以运行的，我并不认为这是一种很好、很正确的想法。并不是说你看到一个模型就可以去执行它，实际上你可以利用一些自动化的工具来执行这个模型。早期的模型应该是不完整的，所以你不能期望它是可运行的。因为这个模型是不完整的，它里面有可能缺少一些必要的数据或者是一些未知的决策，这些都会阻碍这个模型成为可运行的模型。在某些开发模型里我们并不在意这种可运行，因为有些架构设计师他只关注于这种模式，但是并不在意具体的数据结构。这里可以采用的一种技术就是尽早地对架构进行一些测试，有可能还有很多细节不清楚，但是我们还是有办法对架构进行测试的，在IBM内部我们正在开发这种技术。也有人建议把UML变成一种可运行的语言，但是我认为这并不是一个很好的主意。基本的UML实际上是不可运行的，因为UML是一个作用非常广泛的语言。UML在设计时就被设计成用来支持很多种不同的运行平台、很多种不同的编程语言，所以如果想把UML变成可运行的跟你的想法之间就有一定的差距。另外UML本身作为一种建模语言，在其内部缺少了一些运行方面的语意，比如说你是不是需要多任务，还是外部的数据交换的格式等等。怎么样使得UML变得可运行呢？你可以针对某一个特定的运行平台来制定一个特定的UML Profile。比如说有一个现实的例子就是RealTime Profile，这个Profile使得UML可以在实时系统设计这个领域变得可运行。但是大家注意UML本身还是一个通用的描述语言，DSL可能是在很多情况下表述能力都要更强一些。我的想法是可以把UML作为DSL最终实现的过渡语言。我们可以把DSL所描述的语言模型转换成为用UML描述的一个中间产品。然后可以用工具把这种中间化的UML模型进一步转换成特定平台上可以运行的代码。这就等于是构建了从不同的DSL模型到最终可运行平台的转换跟变换。

--类图，就是比你高一点

UML的成功80％是因为类图，提到UML的时候有90％的人想到了类图，应用UML的时候100％应用了类图。如果类图和源代码走到一起，肯定是要代码抗钉耙的，因为论武功和智慧，类图都高了那么一点点。

乱谈类图

如果说程序是一个人，那么类图就是这个人的躯体。也就是说，光有类图，一个程序已经成型了，看上去很像那么一回事了。UML在刻画程序的静态结构方面很成功，但是在刻画程序的动态语义时很失败，至今没有一个好的解决方案，或者说，没有一个能让各方面都接受的方案。如果UML动态语义的问题解决了，那么MDA的目标就真的达到了，模型可以完全代替代码了。

目前的MDA工具，号称模型代码同步的，号称代码生成的，号称PIM/PSM转换的，大部分都只是和类图打交道罢了。因为类图和代码之间的转换是如此自然，以至于出现了Together这样的工具，模型（类图而已）和代码是同步的。

类图是程序的躯体，动作语义才是程序的灵魂，可惜UML在刻画程序灵魂的事情上做得太不出色了。很多研究者仅仅把目光放在类图上，类图到代码的生成几乎已经没有什么可以研究了，还是抱住不放，在生成的代码中加入约束、加入设计模式、加入持久化存储等等。怒其不争、哀其无志。想到自己也是其中的一员，不由临表涕零。

类图难点问题总结

类图是非常容易学习的，因为它和面向对象编程是孪生兄弟，如今的程序员哪有不懂面向对象的，因此类图对于他们，就如同奶瓶对于婴儿一般。下面从硬盘中翻出一幅曾经自己画的类图，相信大家一看便知：

类图是一门易学难精的技术，正如面向对象技术一样，一百个程序员九十九个都说自己懂面向对象，但是真正入门的可能不到十个，真正精通的也许只有一个，这个人还往往不是中国人，唉～

自己重新学习UML的动机就来自于一次论文撰写过程中，想查阅类图的元模型图，但是问遍同行，翻遍网络，找不到合适的图形或者描述，最后只能求救于OMG的UML规范。一查之下，大惊失色，原来很多东西原来都是懵懵懂懂，不甚了了。因此痛下决心，要弄懂类图中的疑点。

翻看类图，我发现有如下是疑点所在：

l         Attribute和Property的关系如何？区别和共同点是什么？

l         完整的描述一个操作（Operation），需要多少东西？

l         类之间可以有关系（Relationship），关系可以是关联（Association）或者泛化（Generalization），这个你知道么？

l         关联有七种：普通关联、递归关联、限定关联、或关联、有序关联、三元关联、聚合（聚合和组合），各自有什么含义？用法如何？

l         关联类（Association Class）的含义如何？应用场景如何？

l         类的实例化是对象，关联的实例化是什么呢？

总结出了这些疑点要归功于中文UML书籍的模糊和混乱，或者是翻译者的语焉不详。所以让我在复习时找出了这么多的疑点。

要查阅资料，解决疑难，并举例说明，起码需要3，4天的时间，因此这篇随笔就作为类图的引文先发了。也希望志同道合者和我一起研究上面的问题。

后记

周末了，想偷懒了，结果适得其反，刚刚完成这篇blog就停电了，后面的几百字全没了。这一点告诉我们，持久化存储是多么重要啊～

--克服用例图的恐惧

在实际工作中，大部分程序员很少接触到需求分析，即使有需求分析，也是草草了事，没有用正规的方式来表达，所以一般程序员使用用例图的机会是不多的。但是却又常常在各种媒体上看见用例图，于是对一种常常出现，自己又不太熟悉的技术，会产生恐惧。如果说对MDA或者CORBA这样的技术产生恐惧还是值得的话，对用例图产生恐惧是非常不值的。因为MDA和CORBA这样的技术也许要花上半年的时间才能够初步了解，而克服用例图恐惧症，则只要不到一天的时间。

用例图初感

UML是一组图示符号的标准。所谓图示符号，就是一组定义好的图示，它们可以表达定义好的各种意思。用UML进行软件建模，就是用规定好的符号画图，这些图表达了开发人员脑中的软件系统。用UML进行软件建模，其难度并不比我们小时候上的美术课更难。在美术课上，一个圆形加上四根线条表示太阳，一个三角形加上一个矩形表示房子；同理，在UML的用例图中，一个椭圆表示用例，一个小人表示参与者。我并不认为它们之间有质的区别，想到我对这种小学生画图课恐惧了几年，不由得感到羞愧。

用例图是UML的九个图中较为重要和常用的一种图。常常用于软件开发的需求分析阶段，也能用于软件的系统测试阶段。简单的来说，用例图是描述系统的外部视图。

在开始设计一个软件系统时（更广义的情况下，可以用来设计任何系统），需要一种手段来发现系统的功能，用例图虽然是图示，但是这些图示隐含了一种启发系统功能的手段。其实所有的UML图都只包含图示和标准，并不包含方法，但是它们往往隐含了某种方法。UML和软件开发方法的关系，很类似于汉字和语文的关系。

用例图包含了三种基本的概念：用例、角色和系统。它们可以组合起来表达系统的外部视图。而且这种表达方式是如此直观和简单。

第一张用例图

画用例图是一件很简单的事情，而且感觉还很舒适，因为用例图简洁、直观。虽然用例图不能像HelloWorld一样运行，也不能生成代码，不过画一张清晰的用例图还是很有成就感的。

我使用的工具是Eclipse+EclipseUML插件，功能不如Rose，但是是开源而且免费的（EclipseUML有free版也有企业版），而且效果也不错。第一张用例图如下：

可以看出图中有一个系统（保险商务系统），两个角色（客户和保险销售员）以及三个用例（签订保险单、销售统计资料、客户数据资料），另外还有四个连接线以及一个注释。如果在纸上或者合适的工具中，画这样一张用例大概只需要五分钟吧。不过仅仅画出来是没有意义的，需要弄清楚其背后真正的含义才行。

理解用例图

可以这样简单的理解用例图中的一些概念，系统（System）指的是软件系统，它可以包含一些用例，并界定系统的边界，边界之内的属于系统的功能和行为，边界之外的则不是系统所关心的内容。系统规定了一个具有某些功能的黑盒子，在系统之外看到的仅仅是这个系统的功能，而不能看到系统的内部细节。这一点也是用例图经常被用来做系统测试的原因。当然这些测试一般是黑盒测试。

角色（Actor）是与系统中的用例交互的一些实体，在实际情况中，角色可以是人，也可以是其他系统或者硬件设备。在画用例图的过程中，角色往往是第一个被确定的，因为系统或者用例在开始时是模糊的，但是参与系统的角色是最容易明晰的。有了角色之后，根据角色与系统的交互，以及角色要求的功能，可以进一步确定系统和用例。

用例（Use case）指的是系统的功能，它是系统某个功能的所有执行动作的集合。在UML图示中它是一个椭圆，但是具体分析用例的时候需要给出这个用例的所有执行动作的步骤。例如上图中的“签订保险单”用例，就可以分为几个步骤：第一，客户发出保险单请求；第二，系统给出保险单样式表；第三，用户填写保险单样式表；第四，系统检查用户提交的保险单格式是否规范；第五，如果不规范则返回第二步，如果规范则给保险单销售员发出消息；第六，保险单销售员填写保险单；第七，保险单销售员将填写好的保险单加入数据库，并将客户资料输入客户数据库。当然，以上步骤仅仅是我想象的，我还从来没有见过什么“保险单”，这次过了一把瘾。

连接（Assocation）是角色与用例的连接，表达此角色可以初始化此用例。 

注释（Note）可以添加到任何地方，对用例图的不同部分加以说明。

泛化、包含和扩展

泛化（Generalization）在面向对象的技术中无处不在，它的另一个名字也许更为著名，就是“继承”。下图给出了一个使用泛化的用例图：

由此可知，在用例图中，角色和用例都能够泛化。角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。

扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。如下图：

小结

关于用例图基本上也就是上面提到的这些内容了。当然，用例图还常常和类图、活动图联合使用，不过那些知识还是等其他知识完备了以后再说比较好。

我总结的画用例图的步骤如下：

l         确定系统，拟出系统的名称，这个不难，例如电信计费系统；

l         找出所有与系统打交道的角色，角色要进行一些精简和整合；

l         站在角色的立场想象系统应该提供的功能，将这些功能画成系统中的用例；

l         对于每个用例给出详细的动作步骤；

l         找出用例图中角色、用例之间可能有的继承、扩展或者是包含关系；

以我现在的理解能力，认为用例图到此为止了。当然，我还可以想象，用例图会用来启发类图的构建，例如用例图中的某些部分（角色或者用例）会变成类图中的类或者接口。另外，可以想象用例图还可能会影响活动图中的流程。

后记

让我恐惧了好久的用例图在今天便土崩瓦解了，心中却彷佛有一点茫然，因为我记得自己无数次的对自己说“好忙啊，这个技术肯定要花很多时间，还是以后再学吧”类似的话。当我用C的时候对C++这样说过，然后是Java、CORBA、JSP、XML、MDA、XMI、UML……

写blog不仅仅是一种爱好，对我来说，更是一种最好的学习方法，当我读小学的时候，班主任常常对我说“好记性不如烂笔头”，我当时的理解是把事情用笔记下来比用脑袋背下来更加持久（脑袋是内存？纸笔是数据库？）。但是，现在我理解到，要学习某个东西，最好的方法是用自己的语言把它表达出来，如果你能让别人理解这个技术，你自己当然已经精通了。在我写blog的过程中，常常会出现写到一半的时候猛然领悟的情况，这是因为当你在选择最佳的表达方式的时候，将你自己头脑中一团乱麻的线索都理清了的结果。

有朋友留言说，自己计算机本科毕业，在计算机领域学习了八年，竟然看不懂我的blog。这个我认为很正常，读本科的时候，所有同学都可以在一起讨论问题、实习；等到上研的时候，同学对我说他的课题，我只能模糊的听个大概，因为专业方向已经分开了；现在读博了，同学要拉着我说他的课题，我只能明白是哪个领域里面的问题，往往对这个问题的描述都听不懂了。这是因为研究方向已经非常精细的原因。我自问我的方向已经很大众化了，如果研究图像压缩算法的话，那满篇都是数学公式了；如果研究微电子技术，那么满篇都是集成电路图了。

还有一点，如果我感兴趣的技术在网上已经能够找到很好的资源，那么我不会动笔去写blog了，我会把资料下载到硬盘就好了。例如XML技术，我的blog中只有两篇，第一篇是“XML的本质讨论”，总结出了别人看不到的XML本质，提出了一些新观点；第二篇是“XSL：转换从哪里开始”。其实XML技术浅显易懂，我也有很多感想和心得，不过其中只有XSL在网上不能找到很好的总结资料，因此我写了那一篇。这也是我坚持原创和创新的一点反映吧。对于那种狂贴别人资料的blog，我是不以为然的。我只喜欢原创或者第一手翻译资料的blog。

UML自1997年诞生以来，受到无数厂商、组织、专家学者的追捧和拥护，短短几年时间，便有一统天下之势。提起建模语言，舍UML其谁？

UML相关标准

OMG组织作为影响力最大的面向对象技术的机构，早早便将UML收入囊中，力捧其为标准建模语言。OMG在CORBA取得成功之后，最大的着力点便是MDA架构，而MDA架构的四大标准UML、MOF、XMI和CWM中，围绕着UML的技术便有三种：UML本身自不必说，版本已经到了2.0；MOF作为“建模语言的语言”，似乎就是为UML量身定做的，虽说MOF有能力创建出与UML并驾齐驱的建模语言，但是似乎没有看到谁这么干，大家只是在努力的发展UML的“方言”，例如UML Profile for CORBA，UML Profile for EJB等等；XMI是“模型的标准存储交换格式”，为了解决不同的建模工具创建的模型不能互用的问题，OMG创建了XMI作为模型的存储交换标准。这样一来，UML工具更加可以大行其道，使用不同的建模工具创建的UML模型可以互相交流，只要它们都基于XMI。

UML相关工具

工具的多寡与优劣可以看出某个技术的受欢迎程度，在建模工具中，不说100％，大概也有90％支持了UML语言。最出名的UML工具Rational Rose，被IBM收购了；Eclipse下面的UML工具EclipseUML让开发它的小公司Omondo也出名了；国内也有一个UML工具，听说效果也不错，就是楚凡科技的Trufun Plato 2005。至于其他国际上有点名气的UML工具，更是不胜枚举，几乎有点软件实力的国家，都有自己的UML工具。

当然，UML不仅仅出现在专用的UML工具中，它也频繁出现在最新的各种开发环境中。例如编程开发环境JBuilder，具有将代码转换为UML类图的功能；Together就更进一步，直接实现了代码和类图的同步转换；Eclipse作为最优秀的开放式开发平台，拥有众多的UML相关插件，除了前面提到的EclipseUML，比较有名的还有EMF和UML2。

UML在MDA出现之后，在OMG的概念中，成为了MDA的一个子集（虽然UML的名气远远大于MDA）。因此众多的MDA工具中，几乎都少不了UML功能。我认为很多MDA工具就是从UML工具直接改过来的。

UML使用现状

照理说来，如火如荼的标准和工具应该催生出如火如荼的应用才对，可是UML的使用状况实在不尽如人意。无论是身边的还是网络上的朋友，在项目中使用UML的都是凤毛麟角，即便使用了UML，也是在很小的范围内，完全没有发挥出1％的功效。现在总结一下目前我所知道的UML使用现状：

l         读代码时，用UML工具进行逆向工程，可以清晰的观察代码结构，方便理解代码。

l         写代码时，由于开发平台可以自动生成UML类图，因此有时观察UML类图得到比较清晰的代码结构。例如Together或者JBuilder等工具。当然，如果没有自动生成的UML图，大部分人也不会寻找其他工具去生成UML类图的。

l         撰写科技论文时，使用UML来表达系统架构或者系统流程等。

l         部分对UML非常熟悉的程序员，在开始写代码时，先画UML类图，然后利用工具生成代码，最后对代码进行扩展。

从上面的使用现状可以看出，很多人把UML当成一种可有可无的技术。即使使用了UML，也只是围绕着UML中的类图，其他的UML图都抛到一边去了。造成这种状况的原因，一方面固然是因为国内的正规大型软件项目比较少，软件工程技术起步很晚；另一方面是由于国内不管是架构师、系统分析员、软件工程师、程序员、测试人员等等实质上都是程序员而已，很多人是赶着鸭子上架成了架构师或者系统分析员的。这种状况下，软件工程的概念难以深入人心，UML更加成了一个国内项目的鸡肋。

看看国外的架构师、UML专家们，往往都是满脸大胡子，在计算机领域中浸淫了3，40年；而中国最古老的程序员，也只有十几年经验，除去在黑暗中摸索的几年，有十年以上开发经验的程序员少之又少。不经历几个大型项目，要使用软件工程技术是不可能的，也是不能起到什么效果的。因此，有人堂而皇之的撰文“UML的三大硬伤”，将UML驳斥得一无是处。高喊口号打倒某东西是很容易的，关键是打倒了UML何以取而代之？

程序员眼中的UML

既然国内90％以上的软件开发人员都是程序员，那么程序员眼中的UML到底应该是什么样子的呢？我很期望有一本好书能够让程序员们快速的掌握自己所需的UML知识，遗憾的是目前还没有看到这样的一本书。无论是“三友”的UML经典教材还是国内的一些“xx天精通UML”都不符合这样的要求。没有一本是“有中国特色的UML教材――一本写给程序员的UML入门书”。

作为一个程序员，我很了解其他同僚的心理，如果拿到一本书，翻了一个小时还没有找到可以run的HelloWorld，90％的人会大叫一声“去nmd”，然后把书扔进废纸堆。不能怪我们急功近利，在这个技术术语满天飞，连底层平台都动荡不安的年代，谁还有时间和兴趣看一些与自己无关的东西呢？

我很能想象一个程序员，好不容易空出时间来看看最近很热的UML技术，当他拿到一本UML入门以后，开始寻找对自己有用的东西。在开始的一个小时，满篇都是需求分析，use case，甚至书的作者还在饶有兴趣的介绍use case有六种译法：用例、用况、用案……对不起，老子一百年都没做过需求分析了，也不想知道这个狗屁的use case到底叫什么。于是开始后悔在china-pub上又白花了这么多银子。

还有些书上信誓旦旦的说“学好UML，走遍天下都不怕”，如果你做需求分析，你可以用UML和客户交流；如果你做系统分析员，你可以用UML设计系统；如果你做程序员，你可以用UML生成程序；如果你做测试员，你可以基于UML设计测试用例。而实际情况是什么呢？国内的客户有几个懂UML？懂UML的人差不多自己都可以把软件写出来了，还需要请你做需求分析么？别说客户了，上次听同学说和北京某大科研所的工程师们交流，无意中说起了UML，在场的竟然只有一个稍微了解，而且坚持认为那是一种画图工具（那位仁兄其实也没错，Visio不就是一个画图工具么）。

虽然状况如此不堪，但是UML确实是一个很优秀的“交流语言”、“代码生成工具”和“系统设计工具”。让我们擦干身上的献血，掩埋战友的尸体，睁大迷蒙的双眼来看清UML对程序员的作用。UML有九种图，作用各自不同，基本上涵盖了软件工程的各个方面，很多人就是不堪于忍受知识不足的困惑与“侮辱”（很多程序员认为一种技术自己看不懂就是对自己的侮辱），从而放弃了整片UML森林。他们怕的不是在UML这棵树上吊死，而是怕在UML森林里面迷路。但是我想说，知识学习的过程就是去芜存精，找出对自己有用的东西，然后掌握之。对于程序员来说，UML的价值就体现在三个方面：

一、UML是最好的交流语言，无论是与其他程序员交流，还是与领域专家、测试员或者用户交流。原因只有一点，UML是标准的，就像英语一样，无论多么该死，大家还是忙着把自己的论文改成英文的。当然，在小的领域可能有更好的交流方言，但是在大而长远的交流中，使用标准的交流语言是稳妥的。

二、UML是很好的代码生成工具，其实代码生成功能并不是由UML语言和规范提供的，而是由UML工具提供的，而且不同的UML工具提供的代码生成功能还不尽相同。例如Rose提供简单的代码框架生成，而Eclipse插件EMF可以生成功能丰富，提供了各种设计模式的代码包。无论如何，如果程序员可以从UML入手来写程序，比直接敲代码要高级那么一点点。从文档、版本控制、维护、测试等各方面来说，画UML类图比直接写代码都要高那么一点点。

三、UML是很好的系统设计工具。对于程序员来说，很少用到“设计”这个词，大部分时候我们都是在“编写”或者“实现”。但是勿庸置疑，程序员的许多工作中还是需要“设计”的。包和组件之间的依赖关系、复杂操作的流程、对象之间的关联和状态、程序的部署等等，都经常是程序员的工作。那么上面的四种情况可以用UML的组件图、序列图、对象图和部署图来设计。虽然，不同的程序员有不同的设计方法或者设计图例，不过，UML是标准的。不要忽视标准的力量，标准的东西意味着在全世界范围内都有可能会被看懂，不标准的东西可能出了你的办公室就没人能够清晰、准确的理解了。

后记

Blog好久没有更新，因为最近一直忙于一些俗物，于是想写点清高的东西。但是写完之后再看，好像也不怎么清高，反而更俗了。

前段时间写论文时，需要用到UML2.0的类图元模型，在UML2.0的规范中寻觅了好久，发现类图元模型已经被拆分到三个包里面了，因为UML2.0的规范实在是太大太繁琐了。于是有感于UML之博大精深，说好听是博大精深，难听点就是乱七八糟。不过OMG历来如此，当初的CORBA如果更简约一点，也许J2EE根本就没有立足之地。

感慨之后就是想把UML中对自己有用的部分整理出来，在整理之前免不了到处翻资料，这篇文档就是翻资料的一些感触了。希望能够将UML的有用部分都整理出来，形成一个系列的文档。

前言

周末的夜晚，总显得特别无聊，总看卫斯理的书不是办法，得找点事情干干。前几天为了验证自己的一个想法，到网上搜索，结果发现了hibernate，为了跑一跑hibernate，结果学习了Ant，最后发现hibernate是一个ORM工具，于是自然把视线转移到了ORM。在网上的资料中游荡，发现对于ORM没有一个完整的中文资料，English的资源也不甚明了。于是有必要把自己所看、所想、所用的做一个小小的总结。

ORM的定义及来由

ORM是Object-Relational Mapping的简称，中文含义是“对象――关系映射”。此处的“对象”，乃是Object Oriented（面向对象技术）中的对象，而“关系”则是关系数据库中的关系。

为什么需要ORM呢？自然是因为需要将对象和关系互相转换，而为什么需要互相转换，就需要解释一下“程序”的概念。最早关于程序的概念是：

程序＝算法＋数据结构

而在信息处理领域，目前我们实际面对的程序概念是：

程序＝数据＋数据处理

计算机的程序有两个大的应用领域：科学计算和信息处理，最初的计算机程序大部分是为了进行科学计算的，这也是为什么在早期的大学中计算机系是数学系的一个分支的原因。而随着计算机技术的不断发展，尤其是网络技术的发展，信息处理已经成为计算机重点关注的问题。“信息技术”（Information Technology，IT）产业也不断发展状态，甚至脱离了计算机技术的领域，自立门派了。说了那么多，其实就是为了说明一个问题，目前的计算机程序，大部分是为了进行信息处理的，而进行信息处理的程序，就等于数据＋数据处理。

而目前程序中的数据大部分是保存在关系数据库中的。目前程序的数据处理流程大部分是用面向对象语言编写的，因此

程序＝关系数据库＋面向对象语言

这个等式在大部分状况下成立。面向对象语言中的基本信息存储单位是“对象”，而关系数据库中的基本信息存储单位是“记录”。那么，当程序需要在数据的处理和数据的存储之间交换信息时，不可避免的要将“对象”和“记录”进行转换。

关系数据库的理论基础是关系代数，面向对象语言的理论基础是面向对象技术，如果能够在具体的程序编写之前解决“对象”和“记录”的映射问题，提出一个通用的解决方案，那么一定能够大大加快程序开发的效率和质量。这个通用的解决方案在部分上已经实现了，就是ORM。

力有未逮，下次再续……

因为本周一要到中南大学作一个学术交流报告，所以上周末一直在准备这个报告的ppt。报告取得了令人满意的结果，本来以为是一个较小范围的报告，没想到来了大概200多研究生，整个小礼堂几乎坐满了。报告从下午4：30持续晚上7：00，4个报告人才完成报告，中途退场的人却很少。本来在我的映像中，能够饿着肚子听报告的研究生应该很少，没有想到中南大学的学生们竟然对此已经习以为常了。在退场之后，大约有20多个学生找研究生会的组织人员签字，原来他们对于研究生的毕业要求中有一项参加报告的次数。不过大部分的同学还是自愿来听的。可以说，好的制度能够营造好的氛围，而好的氛围也容易产生好的制度。

本周中，还给研究生上过两次课，主要还是讲MDA技术的一些概念和工具。刚刚从本科升上来的新硕士们，对于怎样做学问还是一头雾水，吸收知识很快，但是不太懂得如何交流，如何自己去掌握一个知识体系。导师们大多太忙，不能够一一指导，那么个人的悟性往往决定了一个人的研究成果。这是很可悲的一件事情，很多天资很高的学生往往因为忽视了和别人交流而局限在一个很小的圈子里面，浪费了自己的时间和天分。其实，多和自己的师兄师姐们聊聊，能够得到最直接的帮助，有时候我觉得遇到一个好的师兄比遇到一个好的导师更重要。很幸运的是，在我刚刚上硕士时真的遇到了一个好的师兄，不幸的是他毕业太早了。

我们很幸运能够生活在一个网络时代，无限的网络资源带给我们前辈们无法想象的便利。可惜很多人不知道如何利用网络资源，只知道一味的在google上搜索paper，多看paper固然有益，可是往往到达一个高度后无法拔高了。因为你只看到了别人表面的东西，没有了解他们的动机和整个过程。要想提高自己的水平，还是要靠多和人交流。本周在赶一个英文论文，由于很久没有写英文了，其郁闷程度可想而知。幸好在最困难的时候有“MDA和简化开发”qq群里面的兄弟伸出了援助之手，委员向我荣誉推荐归国研究生tom大侠为我修改论文。一时之间，我感动得泪雨滂沱，不能自已。虽然我也偶尔在网上帮别人改改论文，出出点子，但是还是第一次遇到这么得力的帮助，让我深深的感谢网络这个工具。目前已经加入了7个qq群，中有数百个网友，大部分都是讨论某种技术的，有段时间qq实在是不堪重负，每次启动如蜗牛一般，只好忍痛退出了一些qq群。

我也有幸参加过一次国内的学术会议，可是在我看来，彷佛不是开会而是旅游来了。不过无论如何，有两点大的收获：第一知道了国内同行们在关注什么技术，在做什么方面的研究；第二认识了一些志同道合的朋友，可以通过网络进行一些交流。

在我看来，学术是在交流中成长的，只有好的学术氛围，才能够出高水平的成果；只有思维的碰撞，才能擦出最闪亮的火花。说实话，很多国内大学的学术氛围比国外差太远，不过在网络时代，我们终于可以营造属于自己的学术圈子，在网上论战或者开交流会。互联网确实是传统教育的一个最大的补充者。

心有所感，即兴而作，时间仓促，可能有些地方词不达意，如有意见，盼早为告之。

闲聊：

我的BLOG又是一周没有更新了，倒不是因为懒，而是上周的大部分时间花在审阅两篇稿件上了。而尚未发表的稿件不能公开讨论，所以BLOG上面就空空如也了。这几天集中精力读《Object Constraint Language, The: Getting Your Models Ready for MDA, Second Edition》这本书，颇有心得。作者Jos Warmer是OCL的创始人，他对于这门语言的把握是最专业的，而且行文流畅，读原著如同读汉语一样，不由得大发感慨，“好书即是好老师”。全书一共十章，分为两大部分，第一部分User Manual包括前五章，主要讲述OCL的由来、概念、简单的使用和实现方法，以及与MDA的关系等；第二部分Reference Manual内容要深一些，讲述了OCL的一些高级使用方法。

这几天奋起疾“书”，以一天一章的速度看完了前五章，脑中彷佛有豁然开朗之感，尤其对于OCL和MDA的关系有了新的认识。

OCL和MDA的初感想

要谈OCL和MDA之间的关系，先要搞清楚它们各自的定义。OCL的定义上次已经说过了，再贴过来看看：UML图（例如类图）通常不够精细，无法提供与规范有关的所有相关部分。这其中就缺少描述模型中关于对象的附加约束。这些约束常常用自然语言描述。而实践表明，这样做经常造成歧义。为了写出无歧义的约束，已经开发出几种所谓的“形式语言”。传统上的形式语言，缺点是仅适合于有相当数学背景的人员，普通商务或系统建模者则难以使用。OCL即为填补这一空白而来。它是一种保留了易读易写特点的形式语言。它已在IBM的保险分部作为一种业务建模语言开发出来，根植于 Syntropy 方法。

而MDA的定义如下：MDA是OMG提出的一种新的软件开发方法，它定义了基于模型的开发过程，以及自动将模型映射到实现的方法。它提供了一种使用模型来指导系统的理解，设计，构造，开发，操作，维护和修改的方法。

直观的来说，MDA是OMG定义的一种软件开发方法，为了标准化这种开发方法，OMG定义一组规范来支持MDA，其中最重要的有：MOF，UML，XMI，CWM。目前MOF，UML和XMI的最新版本都是2.0（CWM不知道，本身就不熟悉它）。在UML2.0的规范中，用了一个单独的部分来专门定义OCL（OCL在UML的较早版本中已经定义，不过没有作为单独的部分来定义）。这说明，OCL和MDA的关系是：OCL是MDA众多标准中的UML标准中的一个子标准。

但是OCL在MDA中的重要性如何呢？

模型成熟度（Modeling Maturity Levels，MML）

在书中我首次见到了MML的概念，当然不一定是本书作者提出的，只不过是我以前孤陋寡闻罢了。MML指出了模型在你的软件开发过程中扮演了一个什么样的角色？并且指出了为了提高软件开发效率你应该采取什么样的措施。

下图画出了MML的六层示范图：

 

    第零层：没有标准：模型存在于开发者的头脑中；

第一层：文本表达：用自然语言写下想法；

第二层：文本和图：用自然语言以及一些图来表达想法；

第三层：模型和图：用建模语言描述的图来表达模型，用自然语言加以辅助描述；

第四层：精确的模型：用一致而连贯的文本/图来精确的描述模型，它们都是没有歧义的，可以直接映射到编程语言；

第五层：只有模型：第五层的模型是对于系统的一个完备的、一致的、详细和精确的描述。它足以进行全部的代码生成工作，生成的代码不需要任何改动即可运行。总而言之一句话：“模型可运行”！

通过以上MML的描述我们可以了解，如果使用UML来描述模型，但是不使用OCL来描述模型中的约束，那么只能达到第三层。如果使用UML+OCL，那么模型就是精确的，MML可以达到第四层。如果模型可以达到MML5，那么是我睡着了。。。当然我们坚信MML5总有一天会达到，那时我们就可以像使用高级语言一样使用建模语言，而像不理今天的汇编一样不理明天的高级语言。也许有一种叫做MVM（Model Virtual Machine）的东西就像今天的JVM一样流行。

OCL用在了MDA的哪些方面？

从上一节可知，OCL是MDA的必要条件，但远远不是充分条件。但不可否认的是，OCL被广泛用于MDA的各个方面。下面的两张图可以说明一部分问题：

第一张图是MDA的一个典型的开发流程，建立PIM，描述转换定义，利用转换工具将PIM转换为PSM。第二张图是OCL在MDA典型开发流程中的使用。其中三个方面使用了OCL：第一是model的创建使用了OCL来描述模型中的约束；第二是模型转换的定义可以使用OCL来描述；第三是建模语言可以使用OCL来创建。

其中让人迷惑的是第一和第三有什么区别呢？用OCL来约束模型和用OCL来创建建模语言有什么区别？区别在于它们所属元层次的不同，也就是MOF中所描述的模型层次不同。这不是绕口令！其实我刚刚接触MDA的时候也认为模型、元模型、元元模型好像绕口令一样，但这些概念在接触中慢慢清晰起来。用OCL来约束模型是处于M1层，其模型是指对系统的描述，例如对一个信用卡管理系统的UML模型。而用OCL来建立建模语言是处于M2层，这时OCL是用来描述UML的元模型中存在的约束，因为元模型等于模型的语言，也就是用OCL来创建建模语言（可能叫用OCL来定义建模语言中的约束更好）。下面是一个UML元模型中使用OCL的例子：

context Interface

inv: features->select(f |f.oclIsKindOf( Attribute ) )->isEmpty()

这个OCL表达式说明，接口Interface中不能有属性存在。如果UML的元模型中缺少OCL的描述，那么此元模型就不是一个“精确”的元模型，那么UML也就不是一个精确的建模语言了。那么MDA就离我们而去了！

OCL，约束自己，约束父亲

    由上可知，虽然OCL号称“对象”约束语言，其实它可以对MOF的模型层次中的任一层次进行约束，从而表达出精确的模型（四层模型中任一层的模型）。

    OCL可以约束M2层的模型，例如UML的元模型，而OCL的元模型也处于M2层，那么OCL是否可以约束自己的元模型呢？答案是肯定的。

上图是OCL的元模型简化图，其中也用OCL对一些地方进行了描述：

context LoopExpression

inv: source.oclIsKindOf( Collection )

inv: iteratorVariable.type= source.oclAsType(Collection).elementType

    上面的约束表达了LoopExpression中source的类型必须是Collection，而迭代子iterator的类型必须是source这个Collection中的元素的类型。由此可见，OCL的元模型也需要OCL来约束，否则这个元模型就是不“精确”的，可以说，OCL在某种程度上自定义了自己。

从M0（对象），M1（模型）到M2（元模型）都可以用OCL来描述，那么M3层呢？定义UML和OCL元模型的元模型MOF，是否需要用OCL来约束。答案是肯定的！ 随便举一个例子：

[1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e. n-ary Associations are not supported).

context Association inv: memberEnd->size() = 2

[2] The type of Operation::raisedException is limited to be Class rather than Type.

context Operation inv: raisedException.oclIsType(Class)

约束1说明Association的memberEnd的数量必须是2，也就是说Association只能有两个memberEnd；约束2说明Operation抛出的异常类型必须是Class。以上摘自MOF2.0规范。这说明MOF作为OCL的定义者，父亲，同时也被OCL这个儿子约束着。

后记

OCL是MDA中不可缺少的一环，MDA即使离开了UML还有可能使用其他的建模语言来执行，但是离开了约束各层模型的OCL恐怕就处处漏风了。OCL以后很可能会作为一个单独的规范从UML中分离出来。因为它不仅仅是一个“对象”约束语言，更是一个MDA约束语言，渗透在MDA的各个方面。文中还提到了OCL可以定义模型转换，但是由于模型转换的规范QVT还没有最后确定，所以这个部分只是试探，而不是唯一标准。而目前的OCL如果要定义转换，还必须做一些扩充，所以这里没有介绍。

OCL和MDA，目前我的理解也仅限于此，希望看完整本书后，能够有进一步的理解。

为什么要OCL？

OCL的规范是这样解释它的由来：A UML diagram, such as a class diagram, is typically not refined enough to provide all the relevant aspects of a specification. There is, among other things, a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will always result in ambiguities. In order to write unambiguous constraints, so-called formal languages have been developed. The disadvantage of traditional formal languages is that they are usable to persons with a strong mathematical background, but difficult for the average business or system modeler to use.

OCL has been developed to fill this gap. It is a formal language that remains easy to read and write. It has been developed as a business modeling language within the IBM Insurance division, and has its roots in the Syntropy method.

（UML图（例如类图）通常不够精细，无法提供与规范有关的所有相关部分。这其中就缺少描述模型中关于对象的附加约束。这些约束常常用自然语言描述。而实践表明，这样做经常造成歧义。为了写出无歧义的约束，已经开发出几种所谓的“形式语言”。传统上的形式语言，缺点是仅适合于有相当数学背景的人员，普通商务或系统建模者则难以使用。

OCL即为填补这一空白而来。它是一种保留了易读易写特点的形式语言。它已在IBM的保险分部作为一种业务建模语言开发出来，根植于 Syntropy 方法。）

OCL的入门介绍

Mdachina论坛的笨蛋01，提供了OCL的入门教程，我就不再复述了。（注意论坛目前在调整期，地址可能很快过期。不过www.mdachina.net还是可以作为长期的论坛入口）

OCL的特性

OCL之父Addison Wesley在他的著作《Object Constraint Language, The: Getting Your Models Ready for MDA》第二版中详细介绍了OCL的4个特性。

1.       OCL是查询（Query）语言也是约束（Constraint）语言：

A constraint is a restriction on one or more values of (part of) an object-oriented model or system.一个约束就是对一个（或部分）面向对象模型或者系统的一个或者一些值的限制。UML类图中的所有值都可以被约束，而表达这些约束的方法就是OCL。

在UML2标准中，OCL不仅用来写约束，还能够用来对UML图中的任何元素写表达式。每个OCL表达式都能指出系统中的一个值或者对象。因为OCL表达式能够求出一个系统中的任何值或者值的集合，因此它具有了和SQL同样的能力。SQL和OCL都不是约束语言，因为OCL既是约束语言，同时也是查询语言。

2.       OCL是基于数学的，但没有使用数学符号

OCL的基础是数学中的集合论和谓词逻辑，并且它有一个形式化的数学语义。但是它并没有使用某种数学符号。因为虽然数学符号能够清晰的、无歧义的表达事物，但是只有极少的专家可以看懂。所以数学符号并不适合用于一个广泛应用的标准语言。

自然语言是最易懂的，但是它是含混不清晰的。OCL取了自然语言和数学符号的折中方案，使用普通的ASCII字符来表达数学中同样的概念。如果你不喜欢当前的OCL表达方法，OCL规范还允许你定义自己的OCL符号集，这点是可以理解的，因为OCL有一个清晰的数学语义。

3.       强类型的语言

OCL是一个类型语言，任何表达式的值都是属于一个类型的。这个类型可以是预定义的标准类型例如Boolean或者Integer，也可以是UML图中的元素例如对象。也可以是这些元素组成的集合，例如对象的集合、包、有序集合等等。

流行的类型语义有Java，C++等，流行的无类型语言有VB，好像JavaScript也是。

4.       宣言式（Declarative）的语言

Declarative翻译为宣言式的我不知道是否正确，但是对理解其含义并没有影响。与Declarative language相对应的是过程式的语言（procedural language）。过程式语言，类似编程语言，描述了动作执行的步骤。但是在宣言式的语言中，表达式仅仅描述了应该去做“什么”，而不是应该“怎样”去做。为了保证这一点，OCL的表达式是没有副作用的，也就是说，计算一个OCL表达式的值不会对系统的状态产生任何改变。

因为OCL是宣言式语言，所以UML中的表达式被提升到了纯建模的领域，而不必理会实现的细节和实现的语言。表达式在高的抽象层次上规定了系统的值，从而保留了100％的精确。

从游击队到正规军

作为主流的建模语言，UML始终处于不冷不热的地步，老像是游击队，打一枪换一个地方，很难有人将UML自始至终的贯彻。OMG觉得“没有纪律的部队是不能打仗的”，因此加上了OCL这个“军令”，希望能够建设建模领域的“正规军”。但是如果要详细的用OCL描述所有约束，那么在设计阶段花费的时间就会大量增加，是否能够在开发的后期得到效率和质量上的补偿呢？我们只能希望如此。

另外，MML（Modeling Maturity Levels，模型成熟度层次）分为5层，要想能够贯彻MDA方法，模型成熟度必须达到level4，即精确的模型，但是精确的模型目前只能用OCL加UML来描述。所以，OCL也是通向MDA的必经之路。到底它是通向MDA之路的桥梁还是绊脚石呢？