一、什么是元模型?
“元模型”(Meta Model)又称“模型的模型”,是一个高层次的抽象模型,它被用于描述和定义其它模型的结构、语义和行为。元模型本身由实体、属性、关系、规则组成。
•实体:定义对象或基本概念,如男人、女人。
•属性:定义实体的特征,如数据类型。
•关系:定义实体之间的关系,如男人和女人的关系。
•规则:定义模型的语义和行为,如男人的定义是什么。
这么理解元模型还是非常抽象的,接下来,我们再看看元模型的起源和发展吧。
二、元模型的起源与发展
为了解决软件开发中对元模型和元数据管理的需求,成立于1989年全球最大的软件工业标准化组织国际对象管理组织(OMG),大概在1996年的一个征求建议书中提出了MOF的概念。2002年MOF成为了OMG建模系列规范的一部分,并在2005年,采纳为国际标准(ISO/IEC 19502)。随后,MOF进行了大规模版本重构,并于UML对齐。因此,熟悉软件开发或UML的朋友,可以理解为UML中软件建模的模型方法即为元模型建设的方法。
发展至今,MOF被用于定义和管理元模型和模型。
基于MOF框架的元模型框架是目前主流的参考标准,其具备四个基础特点:
四层元模型架构:MOF采用了四层架构(M0、M1、M2、M3),每一层都定义了不同层次的抽象。
开放性和互操作性:MOF规范定义了元模型的标准结构和语义,使得不同工具和平台之间的元模型可以互操作。
扩展性:MOF支持通过扩展来定义特定领域的元模型。MOF是UML、MDA等架构的基础设计框架。
三、如何理解MOF框架?
MOF框架具备经典的四层架构。通过分解四层模型,我们来理解MOF的框架以及元模型设计的初衷。M3元元模型层;M2元模型层;M1模型层;M0模型实例层。

1、元元模型层M3
元元模型层是用来定义元模型的结构的,换句话说就是识别出实体、属性、实体之间的关系以及模型规则。
为了识别出以上元素,就需要了解这些数据的结构、语义描述以及关系(尤其是业务关系)。
我把这个过程理解为微观过程,因为需要我们剖析数据结构,找出数据表中的实体,并识别出实体间的关系和规则。
举例:元素如classes(类)、associations(关系)、Data Types(数据类型)、Constraints(约束)、constants(常数)等。我们要识别这些元素的结构和语义信息。(MOF框架中定义了Class Heading、SuperClass、Contained Elements、Attributes、References、Operations、Constraints、IDL这几类元素;它们组合形成类Class的元模型)。
2、元模型层M2
元模型层完成实例的构建(这是开发语言)。
根据已经识别的元素,由其构成一个类class,即为一个元模型。除了classes元模型,还有关系(Associations)元模型、数据类型(DataTypes)元模型、包(packages)元模型。一个类可以理解为一个实例。所有类的模型层都是在继承类元模型的基础上进行构建的,其他模型亦然。
我把这个过程通俗的理解为,将已经识别的实体、属性、关系用规则关联起来,构成了一个类,用于实现一个特定的功能。这个功能可以是描述实体的关系、定义实体的属性、或设计成一个文件包。
3、模型层M1
根据元模型层确立模型的实体的规则而构建的具体的模型。
我们根据元模型层的信息,已经构建了一个类classes(举例),则Classes的具体结构信息已经进行了明确的定义,这里面包括Class Heading、SuperClass、Contained Elements、Attributes、References、Operations、Constraints、IDL。(这些组成信息共同定义了一个类的结构、行为、约束和与其他类的关系,是面向对象设计和建模中的重要概念。)
在模型设计中,我们通过调用成熟的结构信息,并在其定义本项目相关的结构信息即可完成模型层信息的构建。
我们把这个过程通俗的理解为一个简单的系统,如构建一个人与一个公司关系的系统。
4、模型实例层M0
根据模型层定义的数据结构,完善真实世界的属性数据构成模型实例对象的过程。
这个部分就很好理解。如Company类,属性包括type、name、legal person三个。定义type=民营企业,name=公司名称,legal person=法人姓名,这些具体的属性值的填充就构成了实例对象的数据。
该部分就可以根据Company类和Person类的关系,构建其实体对象图。
四、举例:如何构建元模型
举个例子:要描绘一个人与一个公司的关系的元模型如何构建。定义这个人是公司的所有者。
第一步,识别元元模型层M3层的元素
元素常规的包括:classes(类)、associations(关系)、Data Types(数据类型)、Constraints(约束)、constants(常数)等。我们要识别这些元素的结构和语义信息。
第二步,完成元模型层实例的构建
构建元模型图,完成实例的搭建。类Class由Attribute、Association和Operation组成,其superClass是Class本身。这个类class就是一个元模型,定义了Attribute(属性)、Association(关系)和Operation(操作)与Class的关系。

这个过程完成了由微观元素到中观类的过渡,形成了一个更大的一块代码。整体构成了一个大的实例,完成了对模型层的进一步抽象。比如完成了Company类和Person类的构建。
第三步,根据元模型层实例构建具体的元模型
继续组合Company类和Person类 的关系,建成具体的两个类的关系:一个公司类Company与一个人类Person的具象关系。

其中Company类表示公司的模型,它有三个属性type、name、legal person,另外还有一个关联端owner,表示公司的所有者。其中type、name、legal person构成了属性,与关联端owner一起构成property(property可以包括attribute,也可以包括其他元素,如associations、operation)的实例。可以看出来,M1层模型中的元素是M2层模型元素的实例。如company和person是class实例;type、name、legal person都是attribute的实例;run()和drive()都是Operation的实例。
这个过程其实是用M2的元模型来完成M1层模型的定义。
第四步,完善真实世界的模型属性填充
将真实世界的数据填充到M1中。如Company类,属性包括type、name、legal person三个,定义type=民营企业,name=公司名称,legal person=法人姓名。如Person类,属性包括name、age、gender三个,定义name=张三,age=32,gender=男。这些具体的属性值的填充就构成了实例对象的数据。填充之后,就完成了实体对象图的建设。
结尾的话
元模型作为数据治理中模型的模型,其重要性不言而喻,如何能够从元模型推动数据治理项目实施,这不仅是个能力的问题,也牵涉到战略执行的管理过程。我们期待有更多的从业者能够成为六边形战士,在战略、管理、执行到业务、技术、理论上,能游刃有余,无所不能。
文章内容来自公众号:数据那些事
更多数据治理相关的文章数据治理博客园 | 巨人肩膀
610

被折叠的 条评论
为什么被折叠?



