MOF 思考
MOF 概念总结
一、 概述
元对象设施标准（Meta-Object Facility, MOF）：在一个分布式环境下对元信息的管理进行定义的标准。在“MetaObjectFacility(MOF) Specification”中，由以下章节构成：
l MOFUsage Scenarios：对MOF的使用场景进行了介绍
l MOFConceptual Overview：对整个MOF的4层架构进行了概述，然后对用来描述MOF模型的元素进行了介绍，最后介绍了MOF模型内部和外部的映射。
l MOFModeland Interfaces：详细描述了MOF的自我描述模型元素。
l TheMOFAbstractMapping：从M2到M1的映射。
l MOFtoIDLMapping：从MOF到IDL的映射。
l The ReflectiveModule：反射
二、 MOF框架结构
1. 传统的四层元数据架构
图 1
2. MOF架构
图二是用UML和IDL来表示MOF模型的一个例子。
l MOF的模型描述是采用面向对象的方式进行， 使用UML进行描述。
l 在MOF中，元模型的层次是不定的。在图二是4层结构。
l 一个模型并不一定局限于在一个元模型层次。
l MOF模型是自描述的。
图 二
三、 MOF框架模型元素
图 三
在MOF规范里面，按照Model Classes，Model Associations，Model Data Types，Model Exceptions，Model Constants，Model Constrains等几个方面进行描述。表一按照分类列出了所有的MOF元素，元素里面具体的内容除了IDL其他忽略。
表一
|
类别 |
元素 | |
|
Model Classes |
ModelElement Namespace，GeneralizableElement，TypedElement，Classifier，Class，DataType，PrimitiveType，CollectionType，EnumerationType，AliasType，StructureType，StructureField，Reference，Operation，Association，AssociationEnd，Package，Import，Parameter，Constraint，Constant，Tag
| |
|
Model Associations |
Contains，Generalizes，RefersTo，IsOfType，CanRaise，Exposes，Aliases，DependsOn，Constrains
| |
|
Model Data Types |
MultiplicityType |
struct MultiplicityType { long lower; long upper; boolean isOrdered; boolean isUnique; }; |
|
VisibilityKind， |
enum VisibilityKind {public_vis, private_vis, protected_vis};
| |
|
DirectionKind， |
enum DirectionKind {in_dir, out_dir, inout_dir, return_dir};
| |
|
ScopeKind， |
enum ScopeKind {instance_level, classifier_level};
| |
|
AggregationKind， |
enum AggregationKind {none, shared, composite};
| |
|
EvaluationKind， |
enum EvaluationKind {immediate, deferred};
| |
|
Model Exceptions |
NameNotFound, NameNotResolved
| |
|
Model Constants |
Unbounded |
const long UNBOUNDED = -1; |
|
The Standard DependencyKinds
|
| |
|
Model Constrains |
采用OCL(UML 1.4)来定义，具体待看 | |
|
The PrimitiveTypes Package |
Boolean，Integer，Long，Float，Double，String， | |
|
|
| |
|
|
| |
四、 几类映射(Mapping)
1. MOF Abstract Mapping
目前感觉还比较糊涂，没有理清细节。还需要多想像。
2. MOF to IDL Mapping
3. MOF to IDL XMI Mapping
五、 思考
在看了MDA和MOF这2个规范之后，明白了一件事：规范是非常抽象的东西，如果相关的经验不足的时候，很难看明白。但是，如果不是需要做规范实现方面的工作，或者照着规范的样式做一个类似的东西的时候，是不需要把规范的细节扣得很细的。只要明白一个概念性的东西就差不多了。
Meta这个概念类似与维度。假设有一个装有宇宙里面所有的数据仓库，那么如果要表示宇宙中的任何一个物体，一件事情，都可以从中找到一条数据满足。再假设有一个与这个数据仓库意义等价的元模型，这个元模型可以通过实例化(按照面向对象的思想)的方式来降低抽象程度，以致到最终可以表示任意指定的物体。对于数据仓库来说，通过往上面添加维度进行过滤就可以到最终的数据；对于元模型来说，是通过不断实例化来获得可以表示的数据。
一个类别与这个类别中某一个具体的实例的关系就和面向对象里面的class和object的关系一样，同时类似元模型里面的metadata和data的关系。在C,C++中，采用头文件来定义类型，这个就是元数据。只不过这个元数据与最终的执行代码是分开的。CORBRA和COM采用IDL或者TBL来对接口进行描述，这个是组件层次的元数据。这个元数据也可以和组件分开。到了JAVA和.NET，元数据就不在与执行代码分开，而是绑定在一起。由于这个原因，JAVA与C#都不再把类型的申明和类型的实现分开。
在.NET中，IL的元数据是由41张表组成的，描述了类型相关的所有信息。关系表与面向对象模型的实质上是一回事。用MOF的标准来衡量，.NET的元数据处于M1的层次，定义元数据格式的schema处于M2的层次。因此，如果要在JAVA和.NET中进行mapping，那么可以先在M2层次进行mapping，建立mapping规则，再在M1层次进行mapping。
类，类的实例，类的元数据，继承类等几个概念的关系。首先，类的元数据，类，类的实例在元模型中是从上到下(最上面最抽象)垂直的关系。类的元数据相对于类来说，就是类，类相对于元数据来说就是实例。类这个词的意思就是一类具有相同事物的总称，这是一个抽象的概念。类的实例化就是指定这个类别中的某一个事物的过程。那么什么是继承类？继承类就是在某个类中又加入一些新的限定或者划定一个范围而形成的一个新的抽象。这个抽象是属于之前那个抽象。考虑一个简单的例子。文档模板可以想像成是一个类，它是所有具有类似结构(这个结构可能是文档的排版结构等)的文档的抽象。那么它的实例就是填写这个文档模板而形成的一个文档。文档模板的类或者元数据就是在更高层次上抽象许许多多文档模板而形成的类。文档模板的继承可以在这个文档模板的基础上加入新的格式而形成新的文档模板。
Meta直觉上觉得可以用lisp语言进行描述，有什么优点缺点还没有考虑，只是先mark一下。
先思考到这里，有了想法再更新。
一、 例子
下面考虑了UML Model，C# Model和.NET metamodel之间的MOF层次的对应关系。在UML模型中，采用图形的半形式化的方式来对逻辑进行建模，具有不精确性。静态视图采用类图进行表示，动态试图采用顺序图，活动图等进行表示；C#代码采用面向对象的方式来精确描述逻辑；.NET metadata采用表格的方式对执行代码的类型进行了定义，中间代码(IL, intermediate language)表现了业务逻辑的具体实现。
问题：UML中的顺序图模型，C#中的逻辑操作代码和.NET程序集中的IL是属于M1还是M0？感觉应该是属于M0。因为要进行具体业务逻辑的表示的时候，需要使用M1中定义的类型的实例来进行交互来描述业务逻辑。如果是M1中类型的实例的话，那么抽象层次就降低了，应该属于M0。
图四
在图中有纵向和横向的mapping关系。UML Model，C# Model和.NET metamodel都具有从M2到M1的纵向mapping关系，从M1也可以反射出M2的模型。考虑一个正常的UML建模到生成C#代码，再到编译生成.NET程序集的过程。UML Models对业务逻辑进行了可视化的建模，当转换到C#的代码的时候，需要在M2的层次上建立UML元模型到C#元模型之间的映射，从而为如何从UML Models转换到C# Type建立基础。当C#的代码编译生成.NET程序集，其中绑定了对应代码的元数据。从C#代码到IL中间代码的过程也需要在M2层次上进行C#到IL代码的映射。
|
Layer |
UML Model |
C# Model |
.NET Model | ||||||||||||||||||||||||||||||||||||||||||
|
M1 |
|
Class MOFModel { public int no; private void selfReflect(); } |
TypeDef
FieldDef
MethodDef
| ||||||||||||||||||||||||||||||||||||||||||
|
M2 |
|
MetaClass Type { string name; List <”Field”>; List <”Method”>; } MetaClass Field { string name; string flag; Type type; } MetaClass Method { string name; string flag; Type retype; Param par; } MetaClass Param { …… } |
| ||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
