Model-Driven Architecture

Model-Driven Architecture
王林章软件工程组南京大学计算机科学与技术系

Outline 发展背景、开发方法和相关标准元建模和建模的理论、技术及实现模型转换理论、技术及支撑工具
Software Engineering Group 2009/8/12

背景如何高效、低成本地开发优质的软件产品一直是计算机软件领域重点关注和研究的问题[1]。
[1] Shari Lawrence Pfleeger. Software Engineering: Theory and Practice. 2nd Edition. Upper Saddle River, New Jersey: Prentice Hall, 2001. Software Engineering Group 2009/8/12

软件开发的可行性变量经济可行性取决于：我们能够在何种程度上开发出质量和生命周期与开发成本相匹配的软件系统。

软件产业的发展提高整体的可行性软件产业的发展软件开发方法的发展软件开发整体的可行性是对生产成本、质量和生命周期进行权衡和平衡的结果。
当现有开发方法不能适应软件产业不断增长的需求时，新的开发方法被提出，并推动质量、生命周期和生产成本形成新的平衡。软件开发方法的发展各种不同的新开发方法从不同的角度入手，以不同的方式来实现同一个目标 Software Engineering Group 2009/8/12

提高抽象层次与软件技术发展密切相关的三个要素提高解决问题的抽象层次计算机平台、人的思维模式和问题的基本特征[1]。
在软件开发的长期摸索过程中，人们逐渐认识到“提高解决问题的抽象层次”是有效利用抽象手段解决软件开发问题的一个非常具体而实用的途径。提高抽象层次即是想着符合人的思维模式的方向提高 [1] 杨芙清, 梅宏, 吕建, 金芝. 浅论软件技术发展.《电子学报》, 2002, 30(12A): Software Engineering Group 2009/8/12

两个较为显著的进展 Stephen J. Mellor在21世纪初指出[1]，过去的50多年里，人们利用“提高解决问题的抽象层次”处理软件开发的问题已经取得了两个较为显著的进展：开发出了具有较高抽象层次的程序设计语言；能够在更高抽象层次上实现软件复用。 [1] Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA Distilled: Principles of Model-Driven Architecture. Addison Wesley, 2004. Software Engineering Group 2009/8/12

简单回顾软件开发的发展历史从提高抽象层次的角度简单回顾软件开发的发展历史：以机器为中心的计算以应用为中心的计算以企业为中心的计算
新的压力…… Software Engineering Group 2009/8/12

以机器为中心的计算最早期的程序员以0和1编写机器指令进行开发汇编语言通过助记符提高效率完全面向机器进行开发的方式
程序员仍需要针对物理地址、寄存器和CPU编写代码汇编语言的出现并没有改变以机器为中心开发的方式汇编语言延长了以机器为中心的计算方法的寿命 Software Engineering Group 2009/8/12

从机器指令到汇编语言从基于0和1指令的开发到基于汇编语言的开发，实际上是提高了开发的抽象层次

以应用为中心的计算(1) 从汇编到3GL 第三代编程语言（3GL）的出现大大提高了生产力最早的3GL，如FORTRAN和CORBOL
结构化的3GL，如C和PASCAL 面向对象的3GL，如Smalltalk和C++ Software Engineering Group 2009/8/12

以应用为中心的计算(2) 操作系统虚拟机 3GL提高了编程语言的抽象层次，而操作系统则提升了计算平台的抽象层次
虚拟机执行语言编译器产生的中间代码中间代码可以独立于操作系统 Software Engineering Group 2009/8/12

以企业为中心的计算基于组件开发分布式计算中间件基于组件开发吸取了工业生产过程的经验，致力于创建一个用于可交换组件组装应用程序的世界。
随着网络的产生，计算从单一CPU、机器发展到了分布在网络节点各处的新形态。中间件分布式计算的发展使通过底层网络协议在不同处理器之间传递消息成为新的需求，即屏蔽底层的异构性中间件便是在这样的需求下产生出来的 Software Engineering Group 2009/8/12

应用软件应用软件系统软件系统软件硬件平台硬件平台
中间件应用软件应用软件中间件支撑软件支撑软件系统软件系统软件硬件平台硬件平台 Software Engineering Group 2009/8/12

中间件：提升抽象层次提升平台的抽象层次提升编程抽象层次中间件平台很好的实现了对底层异构环境的屏蔽
中间件提供了一个位于传统操作系统层之上的计算抽象层逐渐形成了三大中间件平台：CORBA、J2EE和.NET 提升编程抽象层次一些中间件还提供了独立于操作系统和编程语言的服务事实上每一种中间件平台都提供了大量的服务，用于延伸自身的能力，并最大限度的锁定用户中间件平台很好的实现了对底层异构环境的屏蔽中间件自身又带来了新的挑战 Software Engineering Group 2009/8/12

中间件分化带来了异构性中间件分化（proliferation）现象新的挑战
上个世纪90年代是软件中间件高速发展的一个时期，支持不同技术标准的中间件产品并存，没有“最终赢家” 企业将为不同中间件应用系统的集成付出昂贵代价企业商业逻辑与特定中间件平台实现技术的“绑定”，提升了信息系统的平台移植难度，加大了企业业务发展受制于某种平台技术发展的风险。新的挑战如何解决企业信息系统建设的互操作性、可移植性、可重用性等问题，成为软件开发领域的重要课题。 Software Engineering Group 2009/8/12

以模型为中心的计算-MDA Varieties of Platforms
Varieties of Hardware Architecture Pentium, PowerPC, PA-RISC, Sparc, 370, … Variety of Networks Ethernet, ATM, IP, SS7, Applealk, USB, Firewire, … Variety of Programming Languages C/C++. Java, VB, C#,… Variety of Operating Systems Unix, Windows, NT/XP. Mainframe, Mobile, … Variety of Middlewares JAVA/CORBA, COM+/.NET, Web Services, …. 2018/9/16

以模型为中心的计算-MDA Integration challenges Integration across middleware
System design across middleware H/W OS App. Middleware Cross Middleware Integration System Design H/W OS App. Middleware H/W OS App. Middleware 2018/9/16

以模型为中心的计算-MDA To allow definition of machine-readable application and data models which allow long-term flexibility of Implementation New implementation infrastructure can be integrated or targeted by existing designs Integration Automate the production of data integration bridges and the connection to new integration infrastructures Maintenance The design is available in a machine-readable form Testing and simulation The developed models can be validated against requirements, tested against various infrastructures and can used to directly simulate the behavior of the system being designed. 2018/9/16

以模型为中心的计算-MDA Role of Models
Capture design information that is usually absent from code and lost during development Basis for System generation Analysis Simulation Test generation Documentation generation …. Domain-specificity of a modeling language strengthens its capabilities for generation, optimization, early error detection, etc. 2018/9/16

OMG的标准从1997年起，OMG以UML为核心陆续颁布了几个重要的技术无关建模标准 2001年，OMG正式推出了框架规范MDA
元对象设施MOF XML元数据交换XMI 公共仓库元模型CWM 2001年，OMG正式推出了框架规范MDA MDA整合了OMG在建模领域发布的一些列标准，成为首个模型驱动软件开发的框架性标准 Software Engineering Group 2009/8/12

Who Are OMG? AT&T BEA Borland Boeing CA Citigroup Compaq Ericsson Ford
Fujitsu Glaxo SmithKline Hewlett Packard Hitachi Hyperion IBM IONA io Software Kabira Kennedy Carter John Deere Microsoft MITRE MSC.Software NASA NEC NetGenics NTT OASIS Oracle Pfizer Rational SAGA Software SAP SAS Institute Secant Siemens Sprint Sun Unisys Vertel Software Engineering Group 2009/8/12

OMG (Object Management Group)
CORBA UML MOF、XMI、CWM MDA Software Engineering Group 2009/8/12

OMG Modeling Activities
1989: OMG established Standardization of Distributed Object Middleware 1995: CORBA 2; 2002: CORBA 3 Modeling Standardization 1997: UML (Unfied Modeling Language) 1997: MOF (Meta Object Facility) 1999: XMI (XML Metadata Interchange) 2001: Application-Specific UML Profiles (EDOC, EAI) Architecture (Reference Model) 1990: OMA (Object Management Architecture) 2001: MDA (Model Driven Architecture) 2001-: starting standardization based on MDA 2018/9/16

OMG Modeling Standards
UML: Unified Modeling Language Address the modeling of architecture, objects, interactions between objects, data modeling aspects as well as the design aspects including construction and assemble. XMI: XML Metadata Interchange A standard interchange mechanism used between various tools, repositories and middleware. MOF: Meta Object Facility Provides the standard modeling and interchange constructs. MDA: Model Driven Architecture Build upon and leveraging the value of OMG’s established modeling standards Can be realized using any major open or proprietary platform, including CORBA, Java, .NET, XMI/XML, and Web-Based platforms. 2018/9/16

OMG Model-Driven Architecture
Provides an open, vendor-neutral approach to the challenge of business and technology change. Separates the specification of the operation of a system from the details of the way that system uses the capabilities of its platform Provides an approach for, and enables tools to Specify a system independently of the platform that supports it Specify platforms Choose a particular platform for the system, and Transform the system specification into one for a particular platform The goals Portability, Interoperability, Reusability through Architectural Separation of Concerns 2018/9/16

MDA Models CIM: Computation Independent Model
A computation independent view of the system Articulates the requirements, but hides the details of implementation and system implementation Bridges the gap between domain experts and technology experts PIM: Platform Independent Model A platform independent view of the system Exhibits a sufficient degree of independence so as to enable its mapping to one or more platforms Achieved by defined a set of services in a way that abstracts technical details. PSM: Platform Specific Model A platform specific view of the system Combines the specifications in PIM with the details that specify how that system uses a particular type of platform CIM PIM PSM 2018/9/16

Model Transformation Model transformation is the process of converting one model to another model of the same system. Marking Metamodel Transformation Model Transformation Pattern Application Model Merging CIM Transformation PIM PSM 2018/9/16

Platform Independent Model (PIM)
The MDA Story Platform Independent Model (PIM) Platform Specific Model (PSM) In CORBA Platform Specific Model (PSM) In ebXML Bridge Implementation In EJB ebXML message Definition 2018/9/16

Impact of MDA on the Development Process
Traditional Lifecycle Process MDA Lifecycle Process Requirement Analysis Desing Coding Testing Deployment Requirement Analysis Desing Coding Testing Deployment Mostly text CIM Iterative Process Diagram & text PIM MDA Process Diagram & text PSM code code Programmer’s shortcut code code 2018/9/16

MDA的主要思想 MDA的主要思想是分离业务功能分析与设计和实现技术与平台之间紧耦合的关系，从而将技术与平台变化对系统的影响降低到最小程度。

MDA对抽象层次的划分与实现技术和平台无关、描述系统设计层次的模型（Platform-Independent Model, PIM）
与具体实现技术和平台相关的应用模型（Platform-Specific Model, PSM） MDA将PIM抽象出来，针对不同实现技术与平台制订多个映射规则，然后通过这些映射规则及辅助工具将PIM转换成PSM，再将PSM不断求精直至形成最后代码。 Software Engineering Group 2009/8/12

PIM Mappings PSM PSM PSM PSM PSM CORBA/CCM J2EE/EJB SOAP/XML DCOM/.NET
CORBA specific platform models PSM EJB specific platform models PSM XML specific platform models PSM .NET specific platform models PSM WEB specific platform models CORBA/CCM J2EE/EJB SOAP/XML DCOM/.NET WEB/WSDL Software Engineering Group 2009/8/12

Building an MDA Application
A Detailed Model, stating Pre- and Post- Conditions in OCL, and Semantics in Action Language Start with a Platform-Independent Model (PIM) representing business functionality and behavior, undistorted by technology details. Platform- Independent Model Software Engineering Group 2009/8/12

Generating Platform-Specific Model
Map a PIM to Specific Middleware Technologies via OMG Standard Mappings MDA tool applies a standard mapping to generate Platform-Specific Model (PSM) from the PIM. Code is partially automatic, partially hand-written. Platform- Independent Model CORBA Model Software Engineering Group 2009/8/12

Mapping to Multiple Deployment Technologies
Map a PIM to Many Middleware Technologies via OMG Standard Mappings MDA tool applies an standard mapping to generate Platform-Specific Model (PSM) from the PIM. Code is partially automatic, partially hand-written. Platform- Independent Model Other Model XML/SOAP Model Java/EJB Model CORBA Model Software Engineering Group 2009/8/12

Generating Implementations
Map PSM to application interfaces, code, GUI descriptors, SQL queries, etc. MDA Tool generates all or most of the implementation code for deployment technology selected by the developer. Platform- Independent Model Other Model XML/SOAP Model Java/EJB Model CORBA Model CORBA Java/EJB XML/SOAP Other Software Engineering Group 2009/8/12

Integrating Legacy & COTS
Reverse-engineering existing application into a model and redeploy. MDA Tools for reverse engineering automate discovery of models for re-integration on new platforms. Platform- Independent Model Other Model Legacy App COTS App Other Software Engineering Group 2009/8/12

Platform- Independent
Automating Bridges Platform- Independent Model Bridge generation is simplified by common application models, simplifying creation of integrated applications both within and across enterprises. MDA Tools combine application and platform knowledge to generate bridges CORBA Model XML/SOAP Model CORBA System Interop Bridge XML/SOAP System Software Engineering Group 2009/8/12

MDA的软件开发生命周期 MDA软件开发生命周期也可以分为需求分析、设计、实现、测试和发布几个阶段，每个阶段都是一个迭代的过程
需求分析阶段的输出是CIM；高层设计阶段通过模型转换从CIM生成PIM；低层设计阶段通过模型转换从PIM生成PSM；代码实现阶段通过模型转换从PSM生成基于特定平台的系统实现代码；迭代测试结束后发布系统。 Software Engineering Group 2009/8/12

MDA带来的好处增强软件复用性增强软件可移植性提高软件开发效率、降低成本降低软件维护成本推动软件自动化进程

MDA带来的好处 Preserving the investment in knowledge Speed of development
Independent of implementation platform Tacit knowledge made explicit Speed of development Most of the implementation is generated Quality of implementation Experts provides transformation templates Maintenance and documentation Design and analysis models are not abandoned after writing 100% traceability from specification to implementation 2018/9/16

MDA的构成 Software Engineering Group 2009/8/12

MDA的核心以下标准或规范构成了MDA的核心：统一建模语言（Uniform Modeling Language, UML），建模工具
元对象设施（Meta Object Facility, MOF），标准的建模与交换结构公共仓库元模型（Common Warehouse Metamodel , CWM），数据仓库的标准基于XML的元数据交换（XML Metadata Interchange , XMI），信息交换的标准格式等。此外，MDA还将标准化少数通用领域的PIM、基于特定于中间件标准的PSM、以及PIM与PSM之间的映射规则，为设计到代码的自动生成提供基础。 Software Engineering Group 2009/8/12

MDA研究热潮 MDA迅速成为研究热点尽管MDA提出的直接动因是为了解决异构中间件（middleware）平台的互操作障碍问题[1]，但是由它所倡导的以模型为中心进行软件开发的思想很快得到了广泛支持，迅速成为研究热点。 [1] 张天, 张岩, 于笑丰, 王林章, 李宣东. 基于MDA的设计模式建模与模型转换. 软件学报, 2008, 19(9): Software Engineering Group 2009/8/12

模型驱动软件开发 “模型驱动软件开发”的出现随着MDA研究热潮的迅速兴起，模型驱动软件开发这个词语逐渐被越来越多的学者使用。
如，model-driven、model-based、model-related、model-engineering等等 Software Engineering Group 2009/8/12

模型驱动工程（MDE）模型驱动工程(Model Driven Engineering, MDE)
2005年，模型驱动软件开发领域最重要的年会之一UML series (International Conference on the Unified Modeling Language)正式更名为MoDELS/UML series (International Conference on Model Driven Engineering Languages and Systems)。 2007年，模型驱动工程这个术语正式出现在第29届ICSE年会的FoSE (the Future of Software Engineering )分会上，可以看做是MDE成为成为模型驱动软件开发领域代名词的标志。 Software Engineering Group 2009/8/12

MDE的核心思想模型驱动工程以模型为首要软件制品（software artifact），通过建模为问题域构造软件系统的业务模型（business model），然后依靠模型转换（model transformation）驱动软件开发，（半）自动地产生最终完备的应用程序[1]。有学者认为模型驱动的思想，或者说以模型为中心的软件开发思想正是抽象层次提高到一定程度的一个自然而然的结果[2]。 [1] Douglas C. Schmidt. Guest Editor's Introduction: Model-Driven Engineering. IEEE Computer. IEEE CS, 2006, 39: [2] David S. Frankel. Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley, 2003 Software Engineering Group 2009/8/12

模型模型的概念模型指的是为了分析或解决问题而对系统某些方面的抽象描述。从广义上看
涵盖了软件系统的任意部分，包括需求、设计、文档、代码、部署、配置和测试用例等。代码也可以看作软件系统的模型从狭义上看通常所指的模型，更多的是狭义上的“设计草图” ，即今天的开发模型。 Software Engineering Group 2009/8/12

挑战建模模型转换 Robert France等将目前这些工作中最重要和亟待解决的问题归结为如下几类挑战：
建模语言的挑战：这一类挑战主要来自于如何使建模语言支持在问题层面上进行建模，以及如何对模型进行严格的分析。关注点划分的挑战：这一类挑战来源于对同一系统进行多视图建模的结果。对模型操纵和管理的挑战：这一类挑战包括了对模型转换的定义、分析和使用；维护模型元素间的可追溯性，以支持模型演化和双向工程；维护不同视点（viewpoint）之间的一致性；版本追踪；在运行期使用模型。建模模型转换 Software Engineering Group 2009/8/12

建模和模型转换模型驱动思想的核心是建模和模型转换建模和模型转换的特点完成MDE开发的两个最主要的过程
建模过程和模型转换过程又是相互交织的建模和模型转换的特点建模过程涵盖了一系列不同抽象层次模型的构造过程相应的转换过程也包括了不同抽象层次间以及相同抽象层次上的转换 Software Engineering Group 2009/8/12

模型转换概观图 Software Engineering Group 2009/8/12

元模型元模型是一个相对的概念元模型和模型是相对而言的，元模型解释了模型元素的含义。
从语言的角度来看，元模型相对于模型而言处于建模语言的层次。而定义元模型的元模型就是所谓的元-元模型。典型的元模型体系分为多个模型层次。 Software Engineering Group 2009/8/12

MDA下的元模型体系 4层元模型体系 MDA下的元模型体系分为4层，由MOF给出最终解释。层次描述元素 M3 M2 M1 M0
层次描述元素 M3 MOF，即定义元素模型的构造集合 MOF类、 MOF属性、 MOF关联等 M2 元模型，由MOF构造的实例组成 UML类、 UML状态、 UML属性、 UML活动等 M1 模型，由M2元模型构造的实例组成 “Customer”类、 “Employee”表 M0 对象和数据，也即M1模型构造的实例客户“张三”员工“李四”员工号“A2004” Software Engineering Group 2009/8/12

M3: 元-元模型 M2: 元模型 M1: 模型 M0: 用户对象 MOF Class name: String UML Class
<<instance of>> <<instance of>> UML Class UML Attribute M2: 元模型 name: String name: String <<instance of>> <<instance of>> <<instance of>> Customer Order M1: 模型 title : String name: String number: String name : String <<instance of>> <<instance of>> Customer Customer Order M0: 用户对象 title = “Dr.” name = “John” title = “Mr.” name = “Mark” number = “A2004” name = “Mary” Software Engineering Group 2009/8/12

Cited from UML2 Specification
Software Engineering Group 2009/8/12 Cited from UML2 Specification

Metamodel Layering When dealing with meta-layers to define languages there are generally three layers that always have to be taken into account: the language specification, or the metamodel, the user specification, or the model, and objects of the model. Software Engineering Group 2009/8/12

模型转换视图其中，MMa和MMb是源模型（source model）和目标模型（target model）的元模型，Ma和Mb是基于此元模型定义的实例模型，Tab是转换规则。 Software Engineering Group 2009/8/12

MDA核心标准 MDA是一个框架性标准，由以下核心标准组成：统一建模语言（Uniform Modeling Language, UML）
元对象设施（Meta Object Facility, MOF）公共仓库元模型（Common Warehouse Metamodel , CWM）基于XML的元数据交换（XML Metadata Interchange , XMI） Software Engineering Group 2009/8/12

Enterprise Computation
MOF Meta-Meta-Model M3 模型语言定义（MOF） UML Meta-Model CWM Meta-Model XMI Meta-Model M2 模型语言（UML、CWM、XMI等） UML Models CWM Models XMI Models M1 应用模型（CIM、PIM、PSM等） Real Systems Enterprise Computation Information M0 客观世界 Software Engineering Group 2009/8/12

Meta-Object Facility MOF is the foundation for models being
exported from one application, imported into another, transported across a network, stored in a repository and then retrieved, rendered into different formats (including XMI, OMG's XML-based standard format for model transmission and storage), transformed, and used to generate application code. Software Engineering Group 2009/8/12

Uniform Modeling Language
统一建模语言 UML(Unified Modeling Language)是一套标准的通用面向对象分析和设计的图形化模型语言。 UML致力于实现软件系统可视化(Visualizing)、规范定义(Specifying)、构造(Constructing)和文档化(Documenting)建模 UML并非MDA框架下强制使用的建模语言，但MDA的各种模型均推荐采用UML进行描述。 Software Engineering Group 2009/8/12

Common Warehouse Metamodel
公共仓库元模型 CWM(Common Warehouse Metamodel)为数据仓库和业务分析领域最为常见的业务与技术相关元数据的表示定义了元模型。 CWM实际上提供了一个基于模型的方法来实现异构软件系统之间的元数据交换。依据CWM建立的数据模型，尽管它们存储于不同的软件系统中，但可以很便利地被整合和集成，进而确保数据挖掘等应用可以跨越企业数据库的边界。 Software Engineering Group 2009/8/12

XML Metadata Interchange
以独立于任何一种开发商或技术的方式提供一种数据交换的标准所谓的“元数据”是指数据的交换可以在元模型层得到很好的支持。目前XMI被广泛使用于MDE各种工具中，作为模型物理存储以及与其他工具交换的中间表示形式。 Software Engineering Group 2009/8/12

元建模相关概念元建模元模型元模型层次元-元模型体系建模语言族 Software Engineering Group
2009/8/20

元建模元建模的相关概念几种主流的元-元模型元建模的层次元建模的根结构 Meta-Object Facility EMF Ecore
AtlanMod KM3 Software Engineering Group 2009/8/20

什么是元建模元建模是相对的元建模和建模的区别元建模的定义(informal) 元建模的概念是相对于元模型和模型而言的
元模型是相对于模型而言的元建模和建模的区别元建模目标是构造元模型建模的目标是构造模型元建模的定义(informal) 元建模是从建模语言的角度来理解模型元素并构造相应的元模型的过程。 Software Engineering Group 2009/8/20

Metamodeling metamodels and models
When metamodeling, we primarily distinguish between metamodels and models. As already stated, a model that is instantiated from a metamodel can in turn be used as a metamodel of another model in a recursive manner. A model typically contains model elements. These are created by instantiating model elements from a metamodel, i.e., metamodel elements. Software Engineering Group 2009/8/20

The typical role of a metamodel
The typical role of a metamodel is to define the semantics for how model elements in a model get instantiated. Note that not all instance-of relationships are shown. Software Engineering Group 2009/8/20

元模型层次元模型层次元模型层次的意义元模型层次的最高层元模型层次定义了一个坐标体系，用于规定模型所处的抽象级别
元模型层次定义同一个语言族提供了层次结构基础每一种建模语言族都有一个特定的元模型层次元模型层次的最高层最高层的元模型用于为建模语言族提供最终解释，并具有自解释的能力 Software Engineering Group 2009/8/20

元-元模型体系元-元模型体系(informal) 指同一个建模语言族所形成的系统每一个元-元模型体系具有一个特定的元模型层次
元-元模型体系有一个唯一的根，即元-元模型，该元-元模型也同时规定了这个体系的最终解释 Software Engineering Group 2009/8/20

建模语言族建模语言族建模语言族（Modeling Language Family）是指由特定元-元模型所定义形成的建模语言家族
之所以需要建模语言族是为了扩展语言的能力例如，在MDA框架下元模型层次为四层，处于最高层的MOF定义了元-元模型的根，UML、CWM、QVT等语言规范都可以由MOF给出解释，因此在MDA中包括MOF在内的所有语言都可以看作同一个预言家族。 Software Engineering Group 2009/8/20

关于MDE中相关概念的说明元建模、元模型、元模型层次、元-元模型以及体系建模语言族是MDE领域常用到的术语，但目前并没有一个一致的定义。

Reflective metamodeling
Reflective disciplines Linguistics, Mathematics, and Computer Science are inherently reflective disciplines. Linguists use language to talk about language. Mathematicians use mathematical methods to study mathematics itself, and Computer Scientists describe descriptions in order to facilitate automation. All the above examples of self-application are variations of a common “meta” theme. Software Engineering Group 2009/8/20

元建模是MDE的内在要求建模语言族的形成依赖于元建模 MDE需要多种不同的建模语言不同的建模语言是通过同一个元-元模型进行定义的
建模语言的定义过程实际上就是元建模过程 MDE需要多种不同的建模语言统一的建模语言，如UML 各种针对特定领域的建模语言DSL，如MARTE, SysML 建模语言的定义和扩展需要元建模的支持 Software Engineering Group 2009/8/20

重要的元-元模型本课程选取以下三个目前主流的元-元模型进行着重介绍 Meta-Object Facility 2.0 Core
MOF 2.0 Core在MOF1.4的基础上进行了改进，主要是为了将MDA的框架标准整合起来。 EMF-ECore ECore的作用不仅仅是作为EMF的元-元模型，同时还扮演了建模语言的角色。它是目前Eclipse下建模工具开发和使用的核心和基础。 AMMA-KM3 KM3是模型转换语言ATL的基础，目前是Eclipse Modeling官方版本的重要插件。同时，KM3也是具有整个AMMA开发平台的核心。 Software Engineering Group 2009/8/20

MOF2.0元模型体系本章节主要内容 MOF的相关背景 MOF的设计理念 MOF四层元-元模型结构 MOF模型的具体构造方法
MOF2.0与UML2.0的尴尬关系 MOF的设计理念 MOF在整个MDA框架中的目标 MOF四层元-元模型结构 MOF模型的具体构造方法如何针对MOF的设计理念实现语言（模型）的构造 Software Engineering Group 2009/8/20

Meta-Object Facility (MOF) 2.0
MOF and UML The OMG adopted the MOF 1.1 in 1997 coincident with the adoption of UML 1.1 as a result of collaboration between the vendors proposing UML 1.1 and MOF 1.1 specifications. This collaboration continues to this day as the vendors working on UML 2.0 Infrastructure and MOF 2.0 are attempting even greater reuse and integration of modeling concepts to provide a solid foundation for MDA. Software Engineering Group 2009/8/20

MOF 2.0 and UML 2.0 MOF 2.0 Core Specification
The specification integrates and reuses the complementary UML 2.0 Infrastructure to provide a more consistent modeling and metadata framework for OMG’s Model Driven Architecture. UML 2.0 provides the modeling framework and notation. MOF 2.0 provides the metadata management framework and metadata services. Software Engineering Group 2009/8/20

MOF and UML UML and MOF are both language specifications
UML is a language specification (metamodel) from which users can define their own models. Similarly, MOF is also a language specification (metamodel) from which users can define their own models. When consider in the MDA view UML is viewed as a user (i.e., the members of the OMG that have developed the language) specification that is based on MOF as a language specification. In the four-layer metamodel hierarchy, MOF is commonly referred to as a meta-metamodel, even though strictly speaking it is a metamodel. Software Engineering Group 2009/8/20

MOF2.0和UML2.0的尴尬关系 MOF的思想是作为独立的MDA元-元模型使用但现实情况是MOF通过复用UML2.0的基础库进行定义
serves as the platform-independent metadata management foundation for MDA 为UML等建模语言提供元模型解释但现实情况是MOF通过复用UML2.0的基础库进行定义 MOF通过复用UML2.0 Infrastructure进行定义 MOF首先定义了相应的复用机制，然后通过这些复用机制对UML2.0 Infrastructure中的基础库进行复用，从而完成自身的定义 Software Engineering Group 2009/8/20

MOF 2.0 Design Rationale The primary purpose of MOF 2.0 is to provide a next-generation platform-independent metadata framework for OMG Ease of use in defining and extending existing and new metamodels and models of software infrastructure. Making the MOF model itself much more modular and reusable. The use of model refactoring to improve the reusability of models. Ensure that MOF 2.0 is technology platform independent and that it is more practical to map from MOF 2.0 to a number of technology platforms. Software Engineering Group 2009/8/20

MOF 2.0 Design Rationale (2)
Orthogonality (or separation of concerns) of models and the services (utilities) applied to models is a very important goal for MOF 2.0. MOF 2.0 models reflection using MOF itself as opposed to just specifying reflection as a set of technology-specific interfaces. MOF 2.0 models the concept of identifier. Reuse of modeling frameworks and model packages at various metalayers by better packaging of MOF ‘Capabilities’. Software Engineering Group 2009/8/20

How many “Meta Layers” Key modeling concepts ≥ 2 layers
The key modeling concepts are Classifier and Instance or Class and Object, and the ability to navigate from an instance to its metaobject (its classifier). This fundamental concept can be used to handle any number of layers (sometimes referred to as metalevels). ≥ 2 layers Basically, MOF 1 and MOF 2.0 allow any number of layers greater than or equal to 2. Software Engineering Group 2009/8/20

Example numbers of layers
Usually less than or equal to four 2 layers: generic reflective systems - Class/Object 3 layers: relational database systems – SysTable/ Table/Row 4 layers: UML 2.0 Infrastructure, UML 1.4 and MOF 1.4 specification - MOF/UML/User Model/User Object Software Engineering Group 2009/8/20

Metamodel Layering When dealing with meta-layers to define languages there are generally three layers that always have to be taken into account: the language specification, or the metamodel, the user specification, or the model, and objects of the model. This structure can be applied recursively many times so that we get a possibly infinite number of meta-layers what is a metamodel in one case can be a model in another case, and this is what happens with UML and MOF Software Engineering Group 2009/8/20

The Four-layer Metamodel Hierarchy
The four-layer metamodel hierarchy is used in the MDA suites of standards meta-metamodeling layer (M3) metamodel layer (M2) model layer (M1) run-time instance layer (M0) Each layer can be viewed independently of other layers, and needs to maintain its own design integrity. Software Engineering Group 2009/8/20

M3: Meta-metamodeling layer
Meta-metamodeling layer (M3) The meta-metamodeling layer forms the foundation of the metamodeling hierarchy. The primary responsibility of this layer is to define the language for specifying a metamodel. MOF is an example of a meta-metamodel. A meta-metamodel is typically more compact than a metamodel that it describes, and often defines several metamodels. Software Engineering Group 2009/8/20

M2: Metamodel layer Metamodel layer (M2)
A metamodel is an instance of a meta-metamodel, meaning that every element of the metamodel is an instance of an element in the meta-metamodel. The primary responsibility of the metamodel layer is to define a language for specifying models. UML and CWM are examples of metamodels. Metamodel are typically more elaborate than the meta-metamodels that describe them, especially when they define dynamic semantics. Software Engineering Group 2009/8/20

M1: Model layer Model layer (M1)
A model is an instance of a metamodel. The primary responsibility of the model layer is to define languages that describe semantic domains i.e., to allow users to model a wide variety of different problem domains, such as software, business processes, and requirements. As for UML, a user model is an instance of the UML metamodel. Software Engineering Group 2009/8/20

M0: Run-time instance of model
Run-time instance of model (M0) The metamodel hierarchy bottoms out at M0. M0 contains the run-time instances of model elements defined in a model. The snapshots (in UML Object Diagrams) that are modeled at M1 are constrained versions of the M0 run-time instances. Software Engineering Group 2009/8/20

如何构造MOF语言核心思想具体方法通过复用UML2.0 Infrastructure中的基础库定义MOF自身的模型
基础库(InfrastructureLibrary)为UML、MOF等提供了公共的核心元素具体方法利用复用机制对基础库中的元素进行重用、扩展以及重组定义MOF自身新的元素以增加MOF的元建模能力 Software Engineering Group 2009/8/20

公共核心元素公共的核心元素(Core package) Core package的定义位置
提供了供MOF、UML、CWM以及Profiles等不用应用的核心可重用元素 Core package的定义位置 Core package被定义在UML2.0 Infrastructure规范中的InfrastructureLibrary里面 Software Engineering Group 2009/8/20

令人费解的重用 the Core package is a complete metamodel particularly designed for high reusability M2 M2 M3 M2 Software Engineering Group 2009/8/20

基础库(InfrastructureLibrary)
基础库是UML2.0 Infrastructure的主要部分，其设计理念是为了满足如下需求： Define a metalanguage core that can be reused to define a variety of metamodels, including UML, MOF, and CWM. Architecturally align UML, MOF, and XMI so that model interchange is fully supported. Allow customization of UML through Profiles and creation of new languages (family of languages) based on the same metalanguage core as UML. 在目标上和MOF有何本质上的区别？ Software Engineering Group 2009/8/20

Architectural Alignment between UML and MOF
Two approaches: Define the common core, which is realized as the package Core In such a way that the model elements are shared between UML and MOF. UML is defined as a model that is based on MOF used as a metamodel Software Engineering Group 2009/8/20

How to harmonize the two requirements？
如何调和这两个要求？ How to harmonize the two requirements？ Software Engineering Group 2009/8/20

调和这两个要求 The InfrastructureLibrary is used at both the M2 and M3 metalevels, since it is being reused by UML and MOF The InfrastructureLibrary is in one capacity used as a meta-metamodel and in the other aspect as a metamodel, and is thus reused in two dimensions. 注：尽管学术界对此存在争议，但这种方法确实提供了一种解决方案。 Software Engineering Group 2009/8/20

两种最主要的复用机制 MOF2中使用的复用机制包引入(Package Importing) 包合并(Package Merging)
在MOF2自身元模型的定义中，主要使用包引入和包合并两种复用机制扩展Infrastructure中的元模型。包引入和包合并的元模型定义在Core::Constructs中包引入(Package Importing) 是一种浅层次的复用机制，使被引入包中所包含的模型在引入包中可见包合并(Package Merging) 是一种扩展性的复用机制，使用被合并包中的模型特征来扩展合并包中对应的模型 Software Engineering Group 2009/8/20

包引入(Package Importing)的语义
A package import is a relationship between an importing namespace and a package 在InfrastructureLibrary中，包引入是一种关系，既可以用于Namespace，也可以用于Package A package indicates that the importing namespace adds the names of the members of the package to its own namespace. 主要用于复用已有的模型元素，而非对其进行扩展类似于Java中的包引入 Software Engineering Group 2009/8/20

包引入的两种可见性包引入支持两种不同的可见性包引入支持对public和private两种不同可见性的模型元素分别进行引入
引入后的模型元素可见性保持不变针对public模型元素的引入称为import 针对private模型元素的引入称为access Software Engineering Group 2009/8/20

图形符号 import和access的图形符号 importing package imported package «access»

包引入示例 The elements in Types are imported to ShoppingCart, and then further imported WebShop. However, the elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced using unqualified names from WebShop. Software Engineering Group 2009/8/20

包合并(Package Merging)的描述
A package merge is a directed relationship between two packages, that indicates that the contents of the two packages are to be combined. This mechanism should be used when elements defined in different packages have the same name and are intended to represent the same concept. Conceptually, a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. Software Engineering Group 2009/8/20

图形符号 A dashed line with a stick arrowhead pointing from the merging package (the source) to the merged package (the target) merged package merging package Software Engineering Group 2009/8/20

包合并(Package Merging)的语义
A package merge between two packages implies a set of transformations The package merge is transformed to a package import having the same source and target packages as the package merge. 合并后的模型通过泛化(Generalization)形成新模型的语义新模型通过泛化关系从target模型获得相应的特征注：package merge的语义是通过转换为package import以及generalization的语义来解释的 Software Engineering Group 2009/8/20

包合并示例 packages P and Q are being merged by package R, while package S merges only package Q Software Engineering Group 2009/8/20

The transformed packages R and Q
Note that the package imports are omitted in the figure. Software Engineering Group 2009/8/20

对上例进行扩充 Additional package merges are introduced by having the package T merge the packages R and S that were previously defined. Aside from the package merges, the package T is completely empty. Software Engineering Group 2009/8/20

The transformed version of T
Again, the package merges have been transformed to package imports. Note that the types of the ends of the associations that were originally in the packages Q and S have all been updated to refer to the appropriate types in package T. Software Engineering Group 2009/8/20

A clearer picture of the end result
It is possible to elide all but the most specific of each classifier. The result of the additional package merges: elided view Software Engineering Group 2009/8/20

MOF对Core的重用和扩展 MOF reuses the UML Core, and then extends the Core with additional packages. Software Engineering Group 2009/8/20

Software Engineering Group
2009/8/20

Essential MOF (EMOF) The value of EMOF is that it provides a straightforward framework for mapping MOF models to implementations such as JMI and XMI for simple metamodels. A primary goal of EMOF is to allow simple metamodels to be defined using simple concepts while supporting extensions (by the usual class extension mechanism in MOF) for more sophisticated metamodeling using CMOF. Software Engineering Group 2009/8/20

EMOF Model- Overview The EMOF model provides the minimal set of elements required to model object-oriented systems. Software Engineering Group 2009/8/20

EMOF Classes The Classes diagram defines the constructs for class-based modeling. EMOF merges InfrastructureLibrary::Core::Basic from UML 2.0 Infrastructure. Therefore, the definition of Classes diagram is provided in UML 2.0 Infrastructure. Note: The Classes diagram discussed here is not UML 2.0 diagrams defined in the Superstructure. Software Engineering Group 2009/8/20

The classes defined in the Classes diagram

Complete MOF (CMOF) The CMOF Model is the metamodel used to specify other metamodels such as UML2. It is built from EMOF and the Core::Constructs of UML2. The Model package does not define any classes of its own. Rather, it merges packages with its extensions that together define basic metamodeling capabilities. Software Engineering Group 2009/8/20

2009/8/20

MOF Summary MOF是MDA的核心标准 MOF并非目前唯一的元-元模型
理解MOF2.0应该结合UML2.0，尤其是Infrastructure MOF并非目前唯一的元-元模型 MOF并非MDE中唯一的元-元模型体系 Ecore和KM3等都具有相同的描述能力，可以相互解释 Software Engineering Group 2009/8/20

模型转换涉及的层次模型转换涉及两个不同层次这里的抽象层次并非MOF中的4个层次不同抽象层次之间的模型转换相同抽象层次内的模型转换

模型转换的抽象层次 MT中抽象层次的说法是从MDA中来的 MDA对抽象层次的划分
用于反映客户的业务需求，与计算无关的模型（Computation-Independent Model, CIM）与实现技术和平台无关、描述系统设计层次的模型（Platform-Independent Model, PIM）与具体实现技术和平台相关的应用模型（Platform-Specific Model, PSM）这里的抽象层次都是在用户模型层次(M1)上 Software Engineering Group 2009/8/20

模型转换框架视图 Software Engineering Group 2009/8/20

目前模型转换所讨论的高低抽象层次都是处于MOF4层结构中的M1层。

模型转换的基本框架两个层次的模型转换所遵循的基本框架是一致的不同抽象层间遵循遵循相同抽象层内具体模型转换的基本框架

具体模型转换的基本框架 Software Engineering Group 2009/8/20

具体模型转换的基本框架转换规则定义层 Software Engineering Group 2009/8/20

具体模型转换的基本框架模型转换实现层 Software Engineering Group 2009/8/20

转换规则定义层转换规则的定义是针对元模型的这是一个单向转换的示例转换规则是针对源模型和目标模型的元模型定义的

转换规则实现层转换规则的实现是指根据规则中定义的源模型的Metamodel将具体模型实例转换为目标模型实例这是一个单向转换的示例

A simple example "Families to Persons" by AtlanMod

MOF-QVT部分 QVT Overview The Relations Language The Core Language
Two Level Declarative Architecture Imperative Implementations Execution Scenarios The Relations Language Supporting tools: MediniQVT, ModelMorf, MOMENT-QVT, Eclipse M2M Relations2ATLVM The Core Language Software Engineering Group 2009/8/20

QVT Overview The QVT specification has a hybrid declarative /imperative nature the declarative part being split into a two-level architecture it forms the framework for the execution semantics of the imperative part Software Engineering Group 2009/8/20

Two Level Declarative Architecture
The declarative parts of this specification are structured into a two-layer architecture A user-friendly Relations metamodel and language A Core metamodel and language Software Engineering Group 2009/8/20

Relations A user-friendly Relations metamodel and language
It supports complex object pattern matching and object template creation Traces between model elements involved in a transformation are created implicitly Software Engineering Group 2009/8/20

Core A Core metamodel and language
It defined using minimal extensions to EMOF and OCL All trace classes are explicitly defined as MOF models Trace instance creation and deletion are defined in the same way as the creation and deletion of any other object Software Engineering Group 2009/8/20

Virtual Machine Analogy
An analogy can be drawn with the Java™ architecture the Core language is like Java Byte Code the Core semantics is like the behavior specification for the Java Virtual Machine the Relations language plays the role of the Java language the standard transformation from Relations to Core is like the specification of a Java Compiler, which produces Byte Code Software Engineering Group 2009/8/20

Execution Scenarios The semantics of the Core (and hence the Relations language): Check-only transformations Single direction transformations Bi-directional transformations Incremental updates when one related model is changed after an initial execution The ability to create as well as delete objects and values Software Engineering Group 2009/8/20

The Relations Language
“关系”的相关概念 Transformations and Model Types Relations and Domains Pattern Matching Keys and Object Creation Using Patterns Restrictions on Expressions 重要概念 Software Engineering Group 2009/8/20

Transformations and Model Types
In the relations language, a transformation between candidate models is specified as a set of relations that must hold for the transformation to be successful. “关系”语言定义的转换是声名式的转换。该转换的基本形式就是一组模型之间关系的声名。 Software Engineering Group 2009/8/20

Model Type Model Type Candidate Model
A specification of what kind of model elements any conforming model can have It is similar to a variable type specifying what kind of values a conforming variable can have in a program Candidate Model A candidate model is any model that conforms to a model type Software Engineering Group 2009/8/20

An example transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) declaration named “umlRdbms” two typed candidate models: “uml” and “rdbms” the model named “uml” declares the SimpleUML package as its metamodel the “rdbms” model declares the SimpleRDBMS package as its metamodel Software Engineering Group 2009/8/20

Transformation Execution Direction
A transformation invoked for enforcement is executed in a particular direction by selecting one of the candidate models as the target. 转换的目标模型只应该有一个。 Software Engineering Group 2009/8/20

Transformation Execution
A transformation can be invoked either to check two models for consistency or to modify one model to enforce consistency The target model may be empty, or may contain existing model elements The execution of the transformation proceeds by first checking whether the relations hold If not, attempting to make the relations hold by creating, deleting, or modifying only the target model Software Engineering Group 2009/8/20

Relations and Domains Relations Domains
Relations in a transformation declare constraints that must be satisfied by the elements of the candidate models. Domains A domain is a distinguished typed variable that can be matched in a model of a given model type. Software Engineering Group 2009/8/20

When and Where Clauses When clause Where clause
The when clause specifies the conditions under which the relationship needs to hold Where clause The where clause specifies the condition that must be satisfied by all model elements participating in the relation It may constrain any of the variables in the relation and its domains Software Engineering Group 2009/8/20

The relation ClassToTable needs to hold only when the PackageToSchema relation holds between the package containing the class and the schema containing the table Whenever the ClassToTable relation holds, the relation AttributeToColumn must also hold. Software Engineering Group 2009/8/20

Top-level Relations A transformation contains two kinds of relations
top-level and non-top-level The execution of a transformation requires that all its top-level relations hold non-top-level relations are required to hold only when they are invoked directly or transitively from the where clause of another relation Software Engineering Group 2009/8/20

Top-level Relations A top-level relation has the keyword top to distinguish it syntactically PackageToSchema and ClassToTable are top level relations, whereas AttributeToColumn is a non-top-level relation Software Engineering Group 2009/8/20

Check and Enforce Whether or not the relationship may be enforced is only determined by the target domain When a transformation is enforced in the direction of a checkonly domain, it is simply checked to see if there exists a valid match in the relevant model that satisfies the relationship. When a transformation executes in the direction of the model of an enforced domain, if checking fails, the target model is modified so as to satisfy the relationship, i.e., a check-before-enforce semantics. Software Engineering Group 2009/8/20

Check and Enforce If we are executing in the direction of uml …
However, if we are executing the transformation umlRdbms in the direction of rdbms … 理解该转换关系的语义需要从两个不同的执行方向上考虑。 Software Engineering Group 2009/8/20

To execute in the direction of uml
If there exists a schema in rdbms for which we do not have a corresponding package with same name in uml, it is simply reported as an inconsistency - a package is not created because the “uml” model is not enforced, it is only checked. Software Engineering Group 2009/8/20

To execute in the direction of umlRdbms
For each package in the uml model the relation first checks if there exists a schema with same name in the rdbms model if it does not, a new schema is created in that model with the given name If is not a corresponding package with the same name in uml, then that schema will be deleted from the rdbms model Software Engineering Group 2009/8/20

Pattern Matching Pattern Matching是Relation Language部分最重要的概念之一 Let us use an example to discuss matching of the patterns associated with domains, known as object template expressions. ClassToTable defines several object template expressions, which are used to match patterns in candidate models. Software Engineering Group 2009/8/20

Pattern Matching是变量和变量名进行匹配的过程。

c: Class Example Pattern matching will bind all the variables in the expression (“c,” “p,” and “cn”), starting from the domain’s root variable “c” of type Class. The variable “p” would already have a binding resulting from the evaluation of the when clause expression PackageToSchema(p, s). Software Engineering Group 2009/8/20

c: Class Example For properties that are compared to variables such as “name=cn” two cases arise If the variable “cn” already has a value binding, then any class that does not have the same value for its name property is eliminated. If the variable “cn” is free, as in our example, then it will get a binding to the value of the name property for all classes that are not filtered out due to a mismatch with other property comparisons. Software Engineering Group 2009/8/20

c: Class Example The property pattern “namespace = p:Package {}”
It will match only those classes whose “namespace” property has a non-null reference to a Package. At the same time, the variable “p” will be bound to refer to the Package. in ClassToTable example Since “p” is already bound in the when clause, the pattern will only match those classes whose “namespace” property has a reference to the same package that is bound to “p.” Software Engineering Group 2009/8/20

Pattern Matching Semantics
This section describes the semantics of the pattern specification construct supported by the relations language. To simplify the description of the semantics we introduce a simple “infrastructure” model of patterns and explain its semantics. Software Engineering Group 2009/8/20

Pattern Infrastructure
To simplify the semantics definition we assume a pattern to have the following abstract structure: Software Engineering Group 2009/8/20

Abstract structure A pattern can be viewed as a graph
the pattern elements, e1, e2, …en, with types <classname1>, <classname2>…<classnamen> respectively, are the nodes of the graph pattern links l1, l2, …lm are the edges the predicate is a Boolean expression that may refer to the pattern elements the predicates may refer to variables other than the pattern elements these are the free variables of a pattern Software Engineering Group 2009/8/20

Matching sub-graphs A pattern is used to find matching sub-graphs in a model A sub-graph of a model consisting of objects o1, o2, …on Software Engineering Group 2009/8/20

Matching sub-graphs A sub-graph of a model consisting of objects o1, o2, …on, matches a pattern as described above if and only if : o1 is of type <classname1> or one of its subtypes, and o2 is of type <classname2> or one of its subtypes, and so on oi and oj are linked by association <assoc1> and ou and ow are linked by association <assoc2>, and so on There exists one or more bindings of values to free variables such that <predicate> evaluates to true when references to e1,e2, …en are replaced by o1, o2, …on respectively. Software Engineering Group 2009/8/20

Value binding Once a pattern has matched
each ei is bound to the corresponding oi each free variable vi is bound to the value with which the <predicate> was evaluated while performing the match Software Engineering Group 2009/8/20

For example Simple UML Model Instance Model Software Engineering Group
2009/8/20

Matching and Binding In the above example X and Y are free variables.
The only sub-graph of the model in the Figure that matches the above pattern is <c1, c1a1> This matching binds X to “c1” and Y to “a1” Software Engineering Group 2009/8/20

Patterns Specifying Collections
The type of elements in a pattern could be a collection such as - Set, OrderedSet, Bag, or Sequence 即ei的类型为集合类型针对集合的匹配与单个元素匹配相似，但需要细化的集合中的所有元素。 Software Engineering Group 2009/8/20

Collection model matches
If the type of ei is a collection of type <classnamei>, then a sub-graph of a model matches the pattern if and only if: oi is a collection of objects from the model of type <classnamei> There is no collection of objects from the model of type <classnamei>, oj such that oi is a sub-collection of oj and replacement of oi with oj will satisfy the other pattern matching criteria. Software Engineering Group 2009/8/20

If lj: <assocname>(em, ei) is a link in the pattern and the type of em is <classnamem>, then every element of oi must be linked to om by the association <assocname>. If lj: <assocname>(em, ei) is a link in the pattern and the type of em is also set of <classnamem>, then every element of oi must be linked to every element of om by the association <assocname>. Software Engineering Group 2009/8/20

For example: The two sub-graphs <c1, {c1a1, a2}> and <c2, {a3, a4}> of the instance model in the Figure match the above pattern. Software Engineering Group 2009/8/20

Object Creation Using Patterns
The object template expression also serves as a template for creating an object in a target model When for a given valid match of the source domain pattern, there does not exist a valid match of the target domain pattern, then the object template expressions of the target domain are used as templates to create objects in the target model. Software Engineering Group 2009/8/20

For example The template associated with Table specifies that a table object needs to be created with properties “schema,” “name,” “column,” and “primaryKey” set to values as specified in the template expression. Software Engineering Group 2009/8/20

Keys and Object Creation Using Patterns
When creating objects we want to ensure that duplicate objects are not created when the required objects already exist In such cases we just want to update the existing objects. The relations metamodel introduces the concept of Key, which defines a set of properties of a class that uniquely identify an object instance of the class in a model. Software Engineering Group 2009/8/20

For example ClassToTable relation
we might wish to specify that in simpleRDBMS models a table is uniquely identified by two properties - its name and the schema it belongs to Software Engineering Group 2009/8/20

Keys and Object Creation
Keys are used at the time of object creation if an object template expression has properties corresponding to a key of the associated class then the key is used to locate a matching object in the model a new object is created only when a matching object does not exist. Software Engineering Group 2009/8/20

Concrete Syntax Textual concrete syntaxes Graphical concrete syntaxes

Graphical concrete syntaxes
There are two ways in which the diagrammatic syntax is used, as a way of: representing transformations in standard UML class diagrams, representing transformations, domains, and patterns in a new diagram form: transformation diagrams. The syntax is consistent between its two uses, the first usage representing a subset of the second. Software Engineering Group 2009/8/20

Graphical concrete syntaxes
The structure of a pattern, as specified by objects and links between them, can be expressed using UML object diagrams. Using object diagrams with some extensions to specify patterns within a relation specification is suggested. UML object diagrams + Software Engineering Group 2009/8/20

UML Class to Relational Table Relation

The where clause - PackageToSchema

UML2REL with constraints

UML to RDBMS Relations Overview
This transformation is uni-directional in direction "rdbms" and maps classes in packages to tables in schemas.UML and RDBMS metamodels UML to RDBMS relation in textual syntax UML to RDBMS relation graphical syntax Software Engineering Group 2009/8/20

Overview This example maps persistent classes of a simple UML model to tables of a simple RDBMS model (three main rules as follows) A persistent class maps to a table, a primary key and an identifying column. Attributes of the persistent class map to columns of the table. … An association between two persistent classes maps to a foreign key relationship between the corresponding tables. 其中attribute到column的映射又分为几种不同情况 Software Engineering Group 2009/8/20

AttributeToColumn Rules
Attributes of the persistent class map to columns of the table an attribute of a primitive datatype maps to a single column an attribute of a complex data type maps to a set of columns corresponding to its exploded set of primitive datatype attributes attributes inherited from the class hierarchy are also mapped to the columns of the table Software Engineering Group 2009/8/20

Simple UML Metamodel Software Engineering Group 2009/8/20

Simple RDBMS Metamodel

UML to RDBMS relation in textual syntax
transformation uml2rdbms(uml:SimpleUML, rdbms:SimpleRDBMS) { top relation PackageToSchema {... } top relation ClassToTable {...} relation ClassToPkey {...} relation AttributeToColumn {...} relation PrimitiveAttributeToColumn {...} relation ComplexAttributeToColumn {...} relation SuperAttributeToColumn {...} top relation AssocToFKey {...} query PrimitiveTypeToSqlType (typename : String) : String {...} } Software Engineering Group 2009/8/20

PackageToSchema -- map each package to a schema
top relation PackageToSchema { pn : String; checkonly domain uml p : SimpleUML::UmlPackage { umlName = pn }; enforce domain rdbms s : SimpleRDBMS::RdbmsSchema { rdbmsName = pn } Software Engineering Group 2009/8/20

ClassToTable Software Engineering Group 2009/8/20
-- map each persistent class to a table top relation ClassToTable { cn : String; prefix : String; checkonly domain uml c : SimpleUML::UmlClass { umlNamespace = p : SimpleUML::UmlPackage { }, umlKind = 'Persistent', umlName = cn }; enforce domain rdbms t : SimpleRDBMS::RdbmsTable { rdbmsSchema = s : SimpleRDBMS::RdbmsSchema { rdbmsName = cn, rdbmsColumn = cl : SimpleRDBMS::RdbmsColumn { rdbmsName = cn + '_tid', rdbmsType = 'NUMBER' rdbmsKey = k : SimpleRDBMS::RdbmsKey { rdbmsColumn = cl : SimpleRDBMS::RdbmsColumn{} } Software Engineering Group 2009/8/20

ClassToTable cont’ when { PackageToSchema(p, s); } where {
ClassToPkey(c, k); prefix = cn; AttributeToColumn(c, t, prefix); Software Engineering Group 2009/8/20

ClassToPkey relation ClassToPkey { cn : String;
checkonly domain uml c : SimpleUML::UmlClass { umlName = cn }; enforce domain rdbms k : SimpleRDBMS::RdbmsKey { rdbmsName = cn + '_pk' } Software Engineering Group 2009/8/20

AttributeToColumn relation AttributeToColumn {
checkonly domain uml c : SimpleUML::UmlClass { }; enforce domain rdbms t : SimpleRDBMS::RdbmsTable { primitive domain prefix : String; where { ComplexAttributeToColumn(c, t, prefix); PrimitiveAttributeToColumn(c, t, prefix); SuperAttributeToColumn(c, t, prefix); } Software Engineering Group 2009/8/20

PrimitiveAttributeToColumn
relation PrimitiveAttributeToColumn { an : String; pn : String; cn : String; sqltype : String; checkonly domain uml c : SimpleUML::UmlClass { umlAttribute = a : SimpleUML::UmlAttribute { umlName = an, umlType = p : SimpleUML::UmlPrimitiveDataType { umlName = pn } }; Software Engineering Group 2009/8/20

PrimitiveAttributeToColumn cont’
enforce domain rdbms t : SimpleRDBMS::RdbmsTable { rdbmsColumn = cl : SimpleRDBMS::RdbmsColumn { rdbmsName = cn, rdbmsType = sqltype } }; primitive domain prefix : String; where { cn = if prefix = '' then an else prefix + '_' + an endif; sqltype = PrimitiveTypeToSqlType(pn); Software Engineering Group 2009/8/20

ComplexAttributeToColumn
relation ComplexAttributeToColumn { an : String; newPrefix : String; checkonly domain uml c : SimpleUML::UmlClass { umlAttribute = a : SimpleUML::UmlAttribute { umlName = an, umlType = tc : SimpleUML::UmlClass { } }; enforce domain rdbms t : SimpleRDBMS::RdbmsTable { primitive domain prefix : String; where { newPrefix = prefix + '_' + an; AttributeToColumn(tc, t, newPrefix); Software Engineering Group 2009/8/20

SuperAttributeToColumn
relation SuperAttributeToColumn { checkonly domain uml c : SimpleUML::UmlClass { umlGeneral = sc : SimpleUML::UmlClass { } }; enforce domain rdbms t : SimpleRDBMS::RdbmsTable { primitive domain prefix : String; where { AttributeToColumn(sc, t, prefix); Software Engineering Group 2009/8/20

AssocToFKey -- map each association between persistent classes to a foreign key top relation AssocToFKey { an : String; scn : String; dcn : String; fkn : String; fcn : String; checkonly domain uml a : SimpleUML::UmlAssociation { umlNamespace = p : SimpleUML::UmlPackage { }, umlName = an, umlSource = sc : SimpleUML::UmlClass { umlKind = 'Persistent', umlName = scn umlDestination = dc : SimpleUML::UmlClass { umlName = dcn } }; Software Engineering Group 2009/8/20

AssocToFKey cont’ enforce domain rdbms fk : SimpleRDBMS::RdbmsForeignKey { rdbmsName = fkn, rdbmsOwner = srcTbl : SimpleRDBMS::RdbmsTable { rdbmsSchema = s : SimpleRDBMS::RdbmsSchema { } }, rdbmsColumn = fc : SimpleRDBMS::RdbmsColumn { rdbmsName = fcn, rdbmsType = 'NUMBER', rdbmsOwner = srcTbl rdbmsRefersTo = pKey : SimpleRDBMS::RdbmsKey { rdbmsOwner = destTbl : SimpleRDBMS::RdbmsTable { }; Software Engineering Group 2009/8/20

AssocToFKey cont’ when { ClassToPkey(dc, pKey); PackageToSchema(p, s);
ClassToTable(sc, srcTbl); ClassToTable(dc, destTbl); } where { fkn = scn + '_' + an + '_' + dcn; fcn = fkn + '_tid'; Software Engineering Group 2009/8/20

PrimitiveTypeToSqlType
query PrimitiveTypeToSqlType (typename : String) : String { if typename = 'INTEGER' then 'NUMBER' else if typename = 'BOOLEAN' then 'BOOLEAN' 'VARCHAR' endif } Software Engineering Group 2009/8/20

Supporting tools Relations currently enjoys the largest tool support.
The medini QVT developed by IKV++ is an Eclipse based interpreter with syntax highlighting editor, code completion, and debugging facilities. A Java-based engine known as ModelMorf, provided by Tata Consultancy, one of the original contributors to QVT. MOMENT-QVT is an MDE project that is based on the term rewriting formalism MAUDE. Software Engineering Group 2009/8/20

IKV++ medini QVT Features Software Engineering Group 2009/8/20
Execution of QVT transformations expressed in the textual concrete syntax of the Relations language Eclipse integration Editor with code assistant Debugger to step through the relations Trace management enabling incremental update during re-transformation Key concept enabling incremental update as well as the transition from manual modeling to automation through transformations in the absence of traces Bidirectional transformations Software Engineering Group 2009/8/20

Demonstration of mediniQVT

The Core Language Core Domains and Pattern Dependencies

Virtual Machine Analogy
An analogy between Core and Relation can be drawn with the Java™ architecture the Core language is like Java Byte Code the Core semantics is like the behavior specification for the Java Virtual Machine the Relations language plays the role of the Java language the standard transformation from Relations to Core is like the specification of a Java Compiler, which produces Byte Code Software Engineering Group 2009/8/20

A starting example An equivalent core mapping to a relation Relation

Core mapping Relation Software Engineering Group 2009/8/20

Comparison with the Relational Language
The Core Language is as powerful as the Relations language, though simpler. The Core language supports pattern matching over a flat set of variables by evaluating conditions over those variables against a set of models. Software Engineering Group 2009/8/20

The following aspects, implied in the relational language, have to be defined explicitly when using the core language: The patterns that match against, and create the instances of the classes that are the trace objects of the transformation (e.g., the links between the transformed model elements). Atomic sets of model elements that are created or deleted as a whole, specified in smaller patterns than commonly specified in the Relational Language. Software Engineering Group 2009/8/20

Transformations In the core language, a transformation is specified as a set of mappings Mappings declare constraints that must hold between the model elements of a set of candidate models and the trace model. A transformation may be executed in one of two modes checking mode or enforcement mode 注：在Core中所定义的转换关系仍是双向的。 Software Engineering Group 2009/8/20

Mappings A transformation contains mappings.
A mapping has zero or more domains. Mapping in Core is just like Relation in Relational language. The structure of a mapping with two domains, one for model type L and one for model type R. Software Engineering Group 2009/8/20

Patterns A pattern is specified as a set of variables, predicates, and assignments. Patterns can depend on each other. A pattern that depends on another pattern may use the variables of that other pattern in its own predicates and assignments More formally: If pattern C depends on pattern S, then C may use variables of S in predicates and assignments of C, and pattern C is always matched using value bindings of the variables produced by a match of pattern S. Software Engineering Group 2009/8/20

Pattern dependency Only the following dependencies between patterns exist: A bottom pattern always depends on the guard pattern above it in the same area. A middle-pattern depends on all domain patterns on the same level (either between guard patterns or between bottom patterns). When a model type called A depends on another model type called B then each pattern of the domain that has model type A depends on the pattern, in the same mapping and on the same level, of the domain that has model type B. Software Engineering Group 2009/8/20

Bindings A match of a pattern results in zero or more valid bindings.
A binding is a unique set of values for all variables of the pattern. A valid binding of a pattern is a binding where all the variables of the pattern are bound to a value other than undefined, and where all the predicates of the pattern evaluate to true. Binding就是形成一组值(values)和变量(variables)之间的对应关系。 Software Engineering Group 2009/8/20

Binding Dependencies A pattern can depend on another pattern.
Predicates in a pattern that depend on another pattern may refer to variables declared in that other pattern. Binding Dependency关系的形成是建立Pattern之间依赖的基础上的。 Software Engineering Group 2009/8/20

Relations to Core transformation
Trace class generation rule Relation-to-mapping - common rule Top-level check-only relation to mapping Top-level enforceable relation to mapping Invoked check-only relation to mapping Invoked enforceable relation to mapping 注：以上6条规则定义了从Relation向Core中的Mapping进行映射的具体方法。 Software Engineering Group 2009/8/20

Rule 1: Trace class generation rule
根据Relation中的映射关系，在Core中显式地定义Trace类注：在Core中trace是以类的形式显式地进行定义的。 Software Engineering Group 2009/8/20

Rule 2: Relation-to-mapping common rule
Rule 2定义了通用的基本规则，由此扩展得到Rule 3和Rule 4 Rule 3: Top-level check-only relation to mapping Rule 4: Top-level enforceable relation to mapping Software Engineering Group 2009/8/20

Rule 3: Top-level check-only relation to mapping
Rule 3通过扩展Rule 2定义得到，主要用于将top和checkonly修饰的relation转换为mapping Software Engineering Group 2009/8/20

Becomes: Software Engineering Group 2009/8/20

Rule 4: Top-level enforceable relation to mapping
Rule 4通过扩展Rule 2定义得到，主要用于将top和enforce修饰的relation转换为mapping Software Engineering Group 2009/8/20

2009/8/20

Rule 5: Invoked check-only relation to mapping
Rule 5通过扩展Rule 3得到，主要用于将在where子句中调用的checkonly的relation转换为mapping Software Engineering Group 2009/8/20

通过where子句调用的关系 Software Engineering Group 2009/8/20

Rule 6: Invoked enforceable relation to mapping
Rule 6通过扩展Rule 4得到，主要用于将在where子句中调用的enforce的relation转换为mapping Software Engineering Group 2009/8/20

通过where子句调用的关系 Software Engineering Group 2009/8/20

Model-Driven Architecture

Similar presentations

Presentation on theme: "Model-Driven Architecture"— Presentation transcript:

Similar presentations

About project

反馈

请登录

Auth with social network:

Model-Driven Architecture

Similar presentations

Presentation on theme: "Model-Driven Architecture"— Presentation transcript:

Similar presentations

About project

反馈