第四章 模型驱动开发途径综述
对象管理组OMG介绍了基于模型的MDA技术，模型是软件开发过程中的关键，MDA软件开发过程是以系统建模作为驱动力的。MDA不同于OMA和CORBA，它是一种在软件开发中使用模型来建立系统和解决互操作性等问题的途径，而不是实现分布式系统的框架。
系统建模是软件开发史上的一次革命。事实胜于雄辩，现在所有的软件开发都有建模过程。不幸的是，很多模型仅仅在编码实现前闪现一下就稍纵即逝。仅在开发者脑中闪现，然后就消失了，对于后来的系统维护人员，简直就是“噩梦”。实际上，我们不应该有任何借口去直接开发软件而不经过仔细的设计，设计可以使得我们的系统易于开发、继承和维护。MDA将使得建模革命更加彻底，因此“将建模革命进行到底！”就成为MDA的一个响亮的口号。
MDA技术的核心概念均是OMG的一系列标准：统一建模语言UML（Unified Modeling Language）、元对象设施MOF(meta Object Facility) 、XML元数据交换XMI（XML metadata Interchange）、公共数据仓库元模型CWM（Common Warehouse metamodel）。MDA的核心标准组成了创建模式驱动的一致性系统纲要的基础，这个系统纲要完成授权、发布和管理模型的功能。
作为OMG组织的一个发展进程，MDA代表了OMG组织定义的互操作性规范的一个革命性进步。很长一段时间以来，互操作性一直基于CORBA标准和服务，不同种类的软件系统在标准的组件接口层次上实现互操作。而在MDA中，它从系统模型层次上来解决互操作性的核心问题。这条途径最有意义的方面就是系统使用平台无关的语言进行描述，使得它和具体的平台以及实现技术分离，同时可以根据各种具体平台的映射关系来生成各种实现模型，例如（Java，XML，SOAP）。
MDA另一各重要的意义就是设立了元模型的规则，元模型在规范中、建模技术中和元数据中都是主要的活跃分子。异构系统之间的互操作最终都是通过共享的元数据、全面的共享和理解元数据的策略来实现的。这些策略包括：自动化部署、发布、管理和翻译模型。AOM技术提供了基于运行时刻翻译模型的动态系统行为。基于AOM的架构可以容易地在运行时刻进行扩展，完全具有动态的行为，因此具有高的互操作性。
1 MDA开发生命周期
MDA开发模式的生命周期与传统的方式看起来区别并不大。他们都具有相同的开发阶段，主要的区别就是各个阶段的设计工件是不相同的，MDA的设计工件是正式的精确模型，它们能够被机器所理解。
图5 模型驱动软件开发过程(设计工件是PIM、PSM)
1.1 MDA开发步骤
图6 MDA开发步骤
1）首先我们使用平台无关模型PIM从如何以最好的方式支持商业逻辑的角度来对系统进行建模。PIM是对系统的一种高层次的抽象，与具体的实现技术无关。在此过程中，我们会不断根据客户需求和其它因素对PIM进行精化，以使得它能够更加精确地描述我们的系统。
2）然后PIM可以被转换到一个或者多个特定平台模型PSMs，对于每种特定的技术平台都会生成独立的PSM。PSM是针对你选择的实现技术、平台，对你的系统度身定做的模型。例如，EJB PSM是对使用EJB结构的系统的建模，它包含一些EJB相关的名称，例如"home interface" "entity bean" "session bean"等。关系数据库PSM包含名称如"table" "column" "foreign key" 等。由于现今的很多系统都跨越多种技术，所以对于一个PIM拥有多个PSM是很正常的。这是MDA中最复杂，也是最重要的一步。
3）有时候从PIM自动生成的PSM并不能使挑剔的程序员满意，他们会根据平台的特性对PSM加以修改，对PSM的改变也能够反映到PIM中去，这是MDA的高级特性。
4）对PSM进行不断的精化，以指导生成器生成质量更高的代码。
5）最后一步就是将每个PSM都转换到代码，由于PSM跟具体的系统实现技术已经很接近，因此这种转换来得比较直接。
1.2 MDA提升了抽象层次
PIM, PSM,和Code模型被作为软件开发生命周期中的设计工件，在传统的开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不同的视角来看待我们的系统，将高层次的PIM转换到PSM的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构，而不会被具体的实现技术所“污染”，同时对于复杂系统，也减少了开发人员的工作量。
2 MDA关注的问题和解决之道
2.1 MDA 提供了统一的元数据管理框架
商业利益的驱使使得软件行业的发展中经常出现各厂商之间产品不兼容的情况，这对于软件相互集成和互操作都形成了障碍，直接导致了软件成本的提高、应用及开发的复杂度。MDA旨在统一不同的商业产品和标准之间的数据交换及互操作，从而改善各厂商的软件产品之间不兼容的情况。
良好的集成性、互操作性的关键是如何智能地使用和管理元数据，这些元数据普遍存在于应用程序、平台、工具和数据库当中。MDA的一个重要贡献正在于提供了一个管理不同元数据的统一框架，元数据的管理和集成可以使用MDA的一系列标准来完成：CWM, MOF, UML和XMI。其中最重要的是MOF，它是MDA的核心部分。和以往进行数据格式统一管理的思路不同，MDA 允许使用不同格式（不同元数据描述）的数据同时存在，并为描述这些数据的语言提供了统一的定义语言，即MOF。下面我们来看看MDA的各个标准在统一元数据方面所起的作用：
2.1.1 CWM
CWM是用来对数据仓库(包括关系型、非关系型、多层系统等)中的元数据进行建模的规范，它为数据仓库、数据挖掘领域内的元数据定义了对应的元模型，它同时也是多层系统、异构系统间元数据实例交换的基础。理解CWM元模型的系统可以使用与其元模型对应的格式进行元数据的交换。CWM包含一系列的元模型，它们分别代表data resources、analysis、warehouse management和典型的数据仓库/数据挖掘环境中的功能组件。Data resource元模型支持对遗产(legacy)和非遗产(non-legacy)的数据源的建模，包括关系型数据库、面向记录(record-oriented)的数据库、基于XML和基于对象的数据源。analysis层定义了data transformations、OLAP、information visualization/reporting、business nomenclature和数据挖掘(data mining)。仓库管理层(warehouse management)定义了标准的warehouse processes、activity tracking和scheduling。foundation元模型支持不同的通用元素和服务，例如数据类型(data types)、类型系统映射(type system mappings) 、抽象关键字和索引(abstract keys and indexes)、表达式(expressions)，商业信息(business information)和基于组件的部署(component-based software deployment)。
每种产品表示元数据的方式不尽相同，它们都有自己的内部格式，因此它们之间元数据的共享就必然存在障碍。现在我们可以使用CWM来解决这一问题，CWM代表了基于模型的在软件系统间交换元数据的一种新途径。在多种产品间共享的元数据将会使用数据模型来表示，而这些数据模型则使用CWM元模型来精确描述。某种产品将自己的元数据(使用内部格式表示)导出为使用CWM描述的元数据，另一种产品将其导入，构造出CWM兼容的模型并映射到自己的内部格式，这样就达到了元数据共享的目的。现在CWM提供的元模型集合已经足以用来对整个数据仓库领域进行建模。使用支持CWM的工具，我们可以从数据仓库模型中直接创建数据仓库实例。不同的工具组件将会处理模型的不同部分，比如，关系数据库服务器将会处理模型中的关系型部分以创建它的分类(catalog)；OLAP服务器将会在模型中搜索OLAP元数据，用它来定义它的多层模式(multidimensional schema)；ETL(extract-transform-load)工具处理的部分可能会跨越多个CWM元模型，例如关系型、OLAP、transformation、data type、type mapping和expression元模型。CWM模型主要是用来定义高度通用的、用于外部表示和共享元数据的模型。对于那些不适合CWM格式的元数据(例如，和工具高度耦合的元数据)，可以通过CWM的扩展机制来处理它，也可以通过扩展核心的CWM元模型来处理它，或者通过其它工具相关的方法来处理。
2.1.2 UML
UML是定义CWM的符号基础(不光是CWM，这里只谈论UML对于统一元数据所做的努力)，但是CWM同时也扩展了核心的UML元模型的子集来支持数据仓库等。使用CWM来构建数据仓库模型的时候，可视化的建模工具是我们的首选。一方面包含复杂的元数据结构的可视化模型对于人来说，易于管理和理解。另一方面，由于UML语言被精确地定义(通过UML元模型)，可视化的UML模型能够被自动地转换到其它格式。这就给交换与平台、工具无关的CWM模型，以及从CWM模型中构造工具相关的元数据都带来了便利性。
2.1.3 MOF
不同的功能需要不同的建模结构集：关系数据建模所需的建模结构包括表、列、键等等。工作流建模所需的建模结构集包括活动、执行者、变化、分割、连接等等。UML类建模所需的建模结构集包括类、属性、操作、关联等等。定义CORBA接口的建模结构集包括接口、值类型等等。
所以，为了描述某一特定类型的模型，我们必须描述组成该类模型的建模结构集。能有一种一致的方法来描述语言结构是非常有用的。业界正在使用全然不同的方法来描述不同类型建模结构的本质。MOF放弃了把这些不同的建模结构集都合并成一个集合的想法，因为这意味着把所有语言合并为一种，而采用统一方式来描述组成某类模型的建模结构属性以及建模结构间的关系。
MOF被用来描述关系数据模型的建模结构，也被用来描述UML类模型的建模结构；它还被用来描述其他种类的建模所用到的结构。MOF是通用的、抽象的，用于定义元模型的语言，它可以被称为metametamodel或者定义元模型的模型。MOF天生就是面向对象的，它定义了基本的元素、语法、元模型的结构。MOF可以作为定义CWM和UML元模型的更通用的模型。
MOF标准提供了：
· 抽象模型：定义MOF对象和他们之间的关联
· 规则的集合：将基于MOF的元模型映射到语言无关的接口(使用CORBA IDL来定义)。对这些接口的实现可以被用来访问和修改任何基于这个元模型的模型。
· 定义元模型元素的生命周期、复合、和关闭语义的规则。
· 层级的反射接口(reflective interfaces)：定义了通用的操作，用于发现(discover)和操纵基于MOF元模型的模型，但是对于映射后的接口的属主是未知的。
MOF的强大在于它使得不同的元模型可以互操作，能够理解MOF的应用程序可以在不了解特定领域模型实例接口的情况下，仍然能够使用反射接口提供的通用操作来读取和更新模型。MOF语义还定义了元数据仓库服务(metadata repository services)，它支持模型构建(construction)、发现(discovery)、移动(traversal)、更新(update)。前提条件是此模型必须是可被理解的某种元模型的实例。MOF支持模型生命周期语义，意味着MOF的实现提供了一种有效的元数据授权和分发工具。例如，新开发的元模型可以保存在MOF仓库中，根据MOF生命周期语义和复合语义(继承inheritance、集群clustering、嵌套nesting等)，它能够和现存的元模型组合。随后，模型接口和默认的实现可以被生成，并对环境可用。模式实现可以通过手工或者工具来附加其它编程逻辑被增强(例如使用OCL约束)。一个完全兼容MOF的仓库可以提供众多的元数据服务，比如持久性(persistence)、版本(versioning)和目录服务(directory services)等。
下面的表和图列出了MOF包含的4个元层次以及其作用：
元 层 次 描 述 元 素
M3 MOF，即定义元模型的构造集合 MOF类、MOF属性、MOF关联等
M2 元模型，由MOF构造的实例组成 UML类、UML属性、UML状态、UML活动等；CWM表、CWM列等
M1 模型，由M2元模型构造的实例组成 “Customer”类、“Account”类；“Employee”表、“Vendor”表等
M0 对象和数据，也即M1模型构造的实例 客户Jane Smith、客户Joe Jones、账户2989、账户2344、员工A3949 、商家78988等
图7 MOF的元层次
M3层是元层次的尽头，层次止于此，因为M3层MOF元素是M3层MOF元素的实例。换句话说，MOF用MOF来描述本身，也就是说MOF是自描述的。MOF为其自身结构定义了一个遵守MOF的模型。该模型常被称为MOF自身模型。MOF自身模型同其余任意MOF元模型均有细微差别：它是MOF的MOF元模型。
2.1.4 XMI
XMI将MOF映射到W3C的XML语言上。XMI定义了XML标记(tags)如何表示序列化的兼容MOF的模型。基于MOF的元模型被转换为DTDs或者XML Schema，模型根据其对应的DTD或者XML Schema被转换为XML文档。以前基于标记的语言在表示对象和对象的关联上存在许多的困难，而这在XMI中得到了解决。此外，XMI基于XML的特性，意味着元数据(用tags表示)和其实例(元素内容)可以共存于同一个文档中，这使得应用程序可以容易地通过其元数据来理解实例。XMI同时具有自描述和天生的同步特性，这就是为什么基于XMI的交换在分布式的、异构环境中是如此重要的原因。
2.2 MDA使得模型变为可执行
MDA开发途径看起来和传统的开发方法很类似，但是这里有一个至关重要的不同，就是模型在MDA中是可执行的，是能够产生产出的。传统意义上，从模型到模型，从模型到代码的转换主要是手工完成的。虽然有些工具可以从模型中产生部分代码，但是它们一般都是通过指定的模板来生成，有很大的局限性，大多数的工作仍然需要手工来完成。
与之形成鲜明对照的是MDA中的转换通常都是通过工具来完成的。许多工具能够将PSM转换成代码。事实上，PSM已经和代码非常接近，这种转换其实没什么稀奇的。对于MDA来说，其重要的改变就是它将从PIM到PSM的转换也自动化了，它是MDA给我们带来的最大的惊喜。想想以前，从详细设计中创建数据库模型要花费我们多少工作？从相同的设计中创建COM组件或者EJB组件要花我们多少时间？现在使用MDA我们可以自动化这一过程。
由于MDA是一种新的框架，现在的工具无法百分之百完成从PIM到PSM，从PSM到代码的转换。开发人员需要手工来完善转换后的PSM或者Code模型，不过现在的工具已经可以从PIM最终产生具备基本功能的可运行的应用程序。这样开发人员可以迅速地验证系统的基本功能，从而进一步优化PIM。
为什么说MDA中的模型是可执行的？因为MDA中的模型的级别处于精确模型级(关于模型级别的讨论请见www.mdasky.com论坛中xiterator的文章《读书报告：建模成熟度级别》)。
精确模型级的模型具有足够的精确度，可与实际代码直接连接（语义距离更小），但模型仍保持高级别的抽象性，而不是编程语言概念的直接表示。该级别的特征是：
· 编码者不再作出任何商业决定。
· 模型与代码的互更新功能成为关注焦点（相对于工具开发商而言），且更容易使用。
· 模型到代码的直接转换（自动化和可定制）方便了迭代和增量的开发。
这里我们可以看出，事实上建模语言在MDA中已经成为了一种编程语言而不仅仅是设计语言，模型所发挥的作用更大了，能够从模型中生成代码，也使得我们对建模的投资获得了更大的回报。
模型转换的内容非常多，限于篇幅，这里不详细介绍，如果大家感兴趣，可以阅读我的《MDA中模型转换的途径》一文
3 Java平台标准在MDA上的努力
采用Java平台来实现这些MDA标准，这是一个明智的实现策略，由于J2EE平台通过提供的公共平台服务和编程模型（接口或者APIs）使得应用程序的开发和集成具有很大的便利性。J2EE正成为实现和发布基于组件的（component-based）、多层系统下的（multi-tiered system）、以Web环境为中心的（Web-centric environments）分布式应用的工业标准的领导者。
Java服务和APIs由JCP(Java Community Process)来开发，JCP目前正在开发将MDA标准映射到Java技术模型中的相关标准，这包括JMI(Java metadata Interface)、JOLAP(Java OLAP Interface)和JDM(Java Data Mining API)。这些都是实现MDA规范的纯Java编程模型，此模型使用J2EE标准APIs的形式，用于将来增强分布式应用程序之间的基于元数据的互操作性。这些即将到来的APIs将为新一代基于模式驱动软件架构的系统提供一个初始的框架。
他们的努力代表了对MDA的自然扩展和延续。事实上，现今明显的趋势J2EE规范中增强了对MOF和CWM元模型的实现。这种趋势是非常重要的，因为它意味着对一致的编程模型、元数据服务、和开放平台的互操作能力的需求是被公认的。
3.1 JMI
Java元数据接口(JMI)提供了将MOF映射到Java语言的正式的映射规则。JMI实现允许生成纯Java接口，以对仓库中的MOF元模型和其实例进行访问。这意味着对MOF元数据服务的Java实现来说，可以提供通用的接口，也可以提供源自MOF接口映射规则的特定元模型的接口，Java客户端可以轻便地通过JMI来访问元数据服务。JMI的开发目前由Unisys领头，参与者包括Sun Microsystems、Hyperion、IBM、Oracle和其它一些行业领导者。
3.2 JOLAP
Java OLAP接口(JOLAP)是为部署在J2EE环境中的OLAP服务器和其应用程序开发纯Java API所做的努力。JOLAP的开发由Hyperion Solutions Corporation领头，参与者包括IBM、Oracle、Unisys、Sun Microsystems和其它一些行业领导者。
在J2EE环境中，JOLAP通常作为OLAP服务器或者其它多维数据库系统的客户端API。JOLAP使用CWM OLAP元模型来描述OLAP元数据，这保证了兼容JOLAP的资源具有完备的互操作性，并能够通过CWM来进行交换。JOLAP同时也定义了查询接口，以支持编写和执行OLAP查询、管理和操纵多维的结果集。JOLAP将会在多个现存的和即将到来的J2EE APIs间起到杠杆作用，包括：
· J2C(Java 2 Connector Architecture)：用于连接管理层、数据层资源、事务管理。
· JMI(Java metadata Interface)：高级元数据功能
· JNDI(Java Naming and Directory Interface)：命名和目录服务，提供single sign-on、认证和鉴权的Java安全模型。
3.3 JDM
Java数据挖掘API(JDM)提供了商业智能应用中数据挖掘技术的纯Java API。JDM和JOLAP类似，它也是对CWM元模型的具体化。JDM的开发由Oracle领导，参与者包括Hyperion、IBM、Sun Microsystems等。
4 众多标准间的关系和在MDA中扮演的角色
4.1 众多标准间的关系
下图说明了MDA中各个标准与对应的J2EE平台标准之间的关系。需要注意的是，对于JOLAP和JDM，对应MDA部分它们主要关注的是元数据管理接口。它们都为数据和查询管理定义了额外的接口，这些都不包含在CWM和MOF中。
图9 MDA中各个标准与对应的J2EE平台标准之间的关系
4.2标准和规约在MDA中扮演的角色
4.2.1 UML在MDA中扮演的角色
UML是使能MDA技术的一把钥匙：使用MDA技术创建的所有应用程序都基于标准化的、平台独立的UML模型。通过将这一通用的、被普遍接受的建模标准作为杠杆，MDA使得开发人员可以创建能被轻便地访问、天生具有良好的互操作性的应用程序。
在MDA中使用UML的方式可以有两种：
1、开发人员使用UML来对系统进行建模，产生PIM。使用UML建立的模型必须具有一致性和精确性，能够被MDA工具理解并能够被转换成模型和代码。
2、软件架构师需要定义用于指导模型转换的规则。他们不开发某个特定系统的模型，而是创建将一种模型转换到另一种模型的规则，这种规则是可以作用于任何模型和不同的系统的。软件架构师必须对UML语言的原理和使用有深刻的了解，同时还必须熟悉UML元模型，因为元模型是用来定义转换规则的重要元素。
4.2.2 MOF在MDA中扮演的角色
通过使用建模语言中的MOF结构定义(位于M2层的元模型)，我们可以定义在建模语言之间的转换规则。由于转换规则使用建模语言的元模型来创建，它们可以被应用到任何模型(位于M1层)中去。如果没有一个标准的语言来描述元模型，那么转换规则就无法创建，那么MDA开发途径的前景将会举步维艰，难以实现。因此，MOF是MDA中的一个核心标准。
4.2.3 OCL在MDA中扮演的角色
为了使源模型(PIM)和语言定义更加精确，OCL可以被有效地用来协助创建转换规则。转换规则将源模型中的模型元素映射到目标模型中的模型元素，OCL query描述了源模型中的模型元素，OCL expression则描述了目标模型中的模型元素。
许多转换规则必须在一定的条件下才能执行，这些条件可以使用OCL来描述。转换规则中使用的所有OCL expressions被应用在源和目标语言的元模型上。先验条件和后验条件
4.2.4 Profiles在MDA中扮演的角色
profile定义了一个特定的元模型，是UML元模型的子集。事实上，profile通过重用UML元模型定义了一种新的建模语言。
在使用的profiles定义了跟特定平台相关的建模语言，比如CORBA、Java和C++ profiles。使用这些profile的模型只能被作为PSM。
4.2.5中间件平台在MDA中扮演的角色
在MDA中，一个规范的PIM被用来定义一个或者多个PSM和接口定义集合。每种定义描述了基础模型在不同的中间件平台上是如何实现的。由于PIM、PSMs和接口定义集合都将被作为MDA规范的一部分，OMG将采用多种中间件平台的规范。CORBA技术具有平台和语言的独立性、经过检验的事务和安全的天性。这使得它仍然是从嵌入式系统到桌面系统，再到Internet应用的最佳选择。MDA的方向是使得它与其他中间件平台更容易交互，而且更加廉价。
