|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-11-14
在MBI的intern主题就是做关于Model driven的工作，其中大部分是插件、rcp的开发，用的技术也主要是EMF，GEF和GMF。其中，EMF是基础，领域模型总是要放在最前面。EMF的对建模提供了好几种方式，用UML工具、java annotation，xmi，xsd等。当然，用UML工具，如EclipseUML是最方便的了。可是如果应用要涉及到xml的话，还是用xml schema吧，而且xml schema也是比较简单的。 虽然xsd的学习成本不大，不过对于xsd和ecore的映射问题，我感觉还是有必要学一下。因为用xsd gen ecore的话，为了得到一个比较满意的ecore，就要用一些ecore的标签。如果想详细了解xsd 的ecore标签，google一下“XML Schema to Ecore Mapping”，介绍的比较详细，我这里只想介绍一点关于connection的知识。 实际上，从xsd到ecore，大部分的映射还是比较简单的。像<xsd:complextype>直接就映射成EClass了，<xsd:attribute>映射成EAttribute。当然，还可以用还多的限定，这里不说了，还是说说关于connection的东西吧。所谓connection，就是面向对象里的关联，聚集之类的概念。</xsd:attribute></xsd:complextype> （1）聚集 A类里有个属性名为container的Elist(注意，如果使用在UML建模的话，以EclipseUML为例，建立关系的时候，要把Property中的Containment设为true)。在xsd里，如何表达这种关系呢。如下： xml 代码
和普通的xsd定义没什么区别。 （2）关联 对于这种方式的联系，EClass会有EReference生成，EReference是non-containment的，所以就不用设置Containment属性了（默认为false）。xsd定义如下： xml 代码
可以看到ecore:reference标签的使用，它会生成一个属性为container的Elist<d></d>。type="xsd:IDREFS"表明0..*。如果type="xsd:anyURI"，则为0..1；type="xsd:IDREF"也为0..1。type="xsd:anyURI"使用了代理，可以关联到不同文档中的其他模型。 双向关联 在这种双向关联中，如果使用EclipseUML，在生成的ecore模型中，C中会有一个名称为ds的Elist<d></d>，D中会有一个名称为cs的Elist<c></c>。xsd定义如下： xml 代码
可以看出，比较单向关联，双向关联增加了<ecore:opposite>属性。当然，EMF并没有硬性的要求这样做，也就是说，在C和D的xsd定义中，<ecore:opposite>属性是可选的，不过还是建议带上它。</ecore:opposite></ecore:opposite> <ecore:opposite><ecore:opposite>最后要说明一些在用xsd建模时需要注意的一些问题：</ecore:opposite></ecore:opposite> <ecore:opposite><ecore:opposite>一般情况下，使用GMF是为了开发工具（这种活在MBI很是常见），所以最后的应用就是带一个pallete，还有一些node啊，edge啊之类的东西。所以在使用xsd建立模型的时候，要注意一些ecore标签的使用。例如，如果将来需要生成一个从C到D的edge边，就像上例那样，那么一定要在xsd中使用<ecore:reference>标签，否则会出问题。如果不需要拖拽一天edeg来建立两个node之间的联系，那么<ecore:reference>标签就无所谓了。通俗点说，如果想通过在将来的pallete里拖拽edge来建立两个node之间的联系的话，在定义xsd时，就要使用<xsd:reference>标签。</ecore:reference></ecore:reference></ecore:opposite></ecore:opposite> 从我个人来讲，比起EclipseUML，我更喜欢直接定义xsd，再gen model。这样在将来的应用中可以更方便的处理xml了。不过这样也会要缺点，尤其是在用到GMF时，可能会产生一些error。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
浏览 3202 次
