Eclipse Modeling Framework (EMF)，简单的说，就是Eclipse提供的一套建模框架，可以用EMF建立自己的UML模型，设计模型的XML格式或编写模型的java代码。EMF提供了一套方便的机制，实现了功能的相互转换，大大提高了效率，下面是其具体功能介绍：

一、统一java、UML、XML

　　为了帮助理解EMF，我们可以举一个例子。假设老板要你写需要写一个程序，来管理供应商的采购清单，采购清单需要维护三大项：付款方(bill to)、运送地址(ship to)和购买货物集合（集合中包含名字name、数量quantity、价格price）。你回答说：没问题。然后就开始设计采购系统的java接口：

1 public interface PurchaseOrder 2 { 3 　　String getShipTo(); 4 　　void setShipTo(String value); 5 　　String getBillTo(); 6 　　void setBillTo(String value); 7 　　List getItems(); // List of Item 8 }  9 public interface Item10 {11 　　String getProductName();12 　　void setProductName(String value);13 　　int getQuantity();14 　　void setQuantity(int value);15 　　float getPrice();16 　　void setPrice(float value);17 }

　　然后就准备开始实现自己的接口，忽然老板问了一句，“你不要先建立自己的模型吗”，对于大多数从来不建模的java程序员，你认为代码就是模型，用那些形式化建模元素建立模型除了能在文档中增加篇幅外，没有任何好处，但即使如此，你仍然要听老板的话，所以你建立了如图1所示的UML模型。

图1 采购系统的UML模型

　　这里，你可以要求老板走开，然后编码实现了，但首先你还得保存模型，这里我们你想到了用XML文件保存，自诩聪明之时，写好了如下的XML schema文件：

1 
      2 
     
       5 　　
      
        6 　　　　
       
         7 　　　　　　
         8 　　　　　　
         9 　　　　　　
        11 　　　　
       12 　　
      13 　　
      
       14 　　　　
       
        15 　　　　　　
        16 　　　　　　
        17 　　　　　　
        18 　　　　
       19 　　
      20 
     

　　在下一步工作之前，你突然意识到现在已经有三种系统表示：Java interfaces、UML模型和 XML Schema，你开始思考，同一个系统设计了三种模型（暂且认为XML和接口也是模型），进行了大量重复的工作，有没有一种方法，只设计其中的一种模型，然后实现三者之间的相互转换？

　　此时，EMF出现了，EMF是一个建模框架，能够实现java代码的生成，即它统一了三种重要的技术：Java, XML 和 UML。如图2所示。

图2 EMF 统一了UML、XML、java

　　假设你要操作一个XML文档，如果你是XML schema大牛，你可以从设计schema开始，然后通过EMF得到UML模型，再通过EMF得到java代码，当然如果你不是，可以从设计UML模型开始，一样可以完成上述功能。

二、建模 vs 编程

　　这里有的人可能会问：难道EMF只是一个描述模型和生成其它东西的框架吗？回答是的，但不全面，EMF的功能远不止此，它能有效地为编程服务，这也是一个经典问题的答案：“我是应该先建模还是直接写代码？”，EMF的回答是两者都可以，因此在EMF看来，两者是等价的。用英语回答就是："To model or to program, that is not the question."

三、定义模型

　　上面我们用三种形式描述了我们的概念模型，那么这三者有没有共同的模型概念，方便它们之间的转换呢（模型转换的知识在此暂时省略）？我们再回顾下前面的三种模型：

• PurchaseOrder and Item 在UML和java中是类，但在XML schema中是复杂类型定义；
• shipTo, billTo, productName, quantity 和 price在UML中是属性，在java中是get()/set()方法对，在XML schema中是内嵌的元素类型；
• items在UML是类的关联或引用，在java中是get()方法，在XML schema中是另一种复杂类型的内嵌元素类型。

　　可以看到这三者都用到了一种较高层的定义来分别表达UML、XML、java。因此，要实现EMF和模型之间的转换，我们需要这种能够描述EMF模型的模型，我们称为元模型。

1、Ecore (Meta)模型

　　能够描述EMF的模型称为Ecore元模型（位于MOF的M2层，关于MOF可以参考），它本身也是EMF模型，因此Ecore是它自己的元模型。如果再深入一点，Ecore的元模型又是什么呢？回答仍然是Ecore，因为它可以描述自身。Ecore只是OMG的MOF在Eclipse下的一种实现，可能还有其它元模型形式（可以参考第二段），这里就不详细介绍了。图3给出了一个简化的Ecore元模型，说它是简化的，是因为它只是Ecore元模型的子集，而且为了方便，将某些公共类省略，如ENamedElement类（这个类定义了类中属性的名字）。

图3 简化的Ecore元模型

　　从图2中可以看到，我们需要四种Ecore类来描述我们的模型，它们是：

• EClass 用于表示模型中的类，它有一个name，0个或多个attributes，0个或多个references。
• EAttribute 用于表示模型中的attribute，它有一个name和一个type。
• EReference 用于表示两个类之间的关联，它有一个name，一个布尔值表示它是否是containment，还有一个引用类型（其它类）。
• EDataType 用于表示attribute的类型，它可以是基本类型，例如int 、 float 或对象类型 java.util.Date等.

　　我们还可以观察到，Ecore元模型这么类似于UML中的类图，这不足为怪，因为UML本来就是一种统一的建模语言（名符其实），倒是有另一点可能不明白？即然Ecore也是UML，为什么不用UML作为UML的元模型呢？答案很简单，因为Ecore只是UML的子集，没有必要用到除类图以外的其它UML元素。

　　有了Ecore元模型，我们就可以用我们的例子实例化Ecore元模型，图4是采购系统的Ecore实例（如果对此不理解，可以参考）。

图4 采购系统的Ecore实例

2、XMI序列格式

　　有了Ecore元模型后，可能有人会问：“Ecore的序列化格式(Serialized form)是什么呢？”是Java code、XML Schema 和 UML diagram中的一种吗？实际上，Ecore的规范序列化格式是XMI(XML Metadata Interchange)，为什么会出现另外一种XMI格式，而不用前面介绍的三种格式呢？首先，Java code、XML Schema 和 UML diagram都增加了Ecore本身并不具有的信息，已经改变了Ecore；其次，Java code、XML Schema 和 UML diagram中没有一种能够适用于任何场合，即没有一种是通用的，而XMI正好满足这两点。我们的采购系统Ecore实例可以用下面的XMI序列表示：

 

　　 当我们听到别人要导出EMF模型时，实际上就是导出EMF的XMI。

 3、java注释

　　我们已经知道EMF能够将java接口自动生成UML的属性和方法，但是否所有的接口都能生成呢？或者什么样的接口才能生成呢？首先，EMF并不会盲目地把所有的java接口自动生成UML的属性和方法，其次，只有符合特定规范才能通过EMF生成（EMF使用的是JavaBeans简单属性祖先命名模式的子集，具体规范可参考http://java.sun.com/products/javabeans/docs/spec.html）。根据此规范，需要用@model标明哪些接口需要用EMF生成模型。例如前面给的PurchaseOrder接口就需要用下面的格式来生成UML：

/** * @model */public interface PurchaseOrder{ /** * @model */　　String getShipTo(); /** * @model */　　String getBillTo(); /** * @model type="Item" containment="true" */　　List getItems();}

 

4、Ecore "Big Picture"

　　我们先来回顾前面的知识：

• Ecore和它的XMI序列化格式是EMF的核心；
• EMF模型至少可以通过三种形式得到（UML、XML schema、Java 接口）；
• 通过Ecore模型可以生成Java接口及其它形式的模型；

　　其实，通过XML schema定义模型有一个优势：给定schema后，可以序列化成持久模型的实例。因为XML schema不仅仅定义了模型，还指定了模型实例的持久格式。问题出来了：是否还有其它的持久模型格式呢？回答是肯定的，例如relational database (RDB) Schema等。Ecore的"big picture"如图5所示。

图5 Ecore及其源格式

四、生成代码

　　EMF最主要的功能莫过于其自动代码生成能力了，能够极大提高工作效率。假设我们已经有了上面的模型，生成转换成Java代码呢？你只要新建EMF项目，它即自动加载了生成器。那么，EMF生成是的是什么样的代码呢？

　　首先，Ecore类（即EClass）相当于java的两个实体：接口及其实现类。例如对于EClass PurchaseOrder相当于java的：

public interface PurchaseOrder ...public class PurchaseOrderImpl extends ... implements PurchaseOrder {

 

　　是这种设计方式，是因为我们认为这是类模型API（如文档对象模型DOM）的最好模式。

　　其次，每个生成的接口都直接或间接扩展了基接口EObject，如：

public interface PurchaseOrder extends EObject {

 

　　EObject是java.lang.Object的EMF等价物，即所有模型对象的基础。扩展的EObject包含下面三种行为：

• eClass()返回对象的元对象（是一个EClass）。
• eContainer() and eResource() 分别返回对象的包含对象及其资源。
• eGet(), eSet(), eIsSet(), and eUnset() 提供了访问交互对象的API。

　　然后，EObject还是另一个接口的扩展：

public interface EObject extends Notifier {

 

　　最后，根据类型及用户设定的属性生成代码。例如：

public String getShipTo(){　　return shipTo;}

 

　　对于相应的set()会有点不同，它会对其它可能对此属性状态改变的观察者发出通知，如：

public void setShipTo(String newShipTo){　　String oldShipTo = shipTo;　　shipTo = newShipTo;　　if (eNotificationRequired())　　　　eNotify(new ENotificationImpl(this,　　　　　　　　　　　　　　　　　　　　　　Notification.SET,　　　　　　　　　　　　　　　　　　　　　　POPackage.PURCHASE_ORDER__SHIP_TO,　　　　　　　　　　　　　　　　　　　　　　oldShipTo, shipTo));}

 

　　注意到当没有观察者时，为了避免调用eNotify()花费的高昂代价，EMF会添加一个eNotificationRequired()守卫条件。

五、总结

　　本篇由浅入深的介绍了EMF的相关知识，由于篇幅原因，不可能将全部的EMF知识都写在这里，感兴趣的读者可以通过参考书籍了解其它内容。

六、参考资料

　　1. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: Eclipse Modeling Framework, 2nd Edition. Pearson Education (2008)