1 建立并积累自己的开发体系
遵行业界的规定又有自己的特色是我们所追求的目标。成功的软件公司都有丰富而可复用的代码组件，几行代码在单个系统里可能无足轻重，但一旦可在大量的系统中可重复使用那就是价值不菲了。做单个项目不一定获利，但用前面的项目经验与代码改造成新项目的成本就少多了。所以，软件业一定要建立起自己的知识库并不断地积累，那将是取之不尽的财富。
2 建立可重用性的知识库
l 充分利用开发模板
利用我们自己开发的模板组装我们一般的页面，极大的减少了页面设计代码和开发代码，提高开发效率。
此模板中包括页面的风格控制，通用的翻页组件，通用的操作功能如打开一个页面，删除，增加，退出等。
l 控件管理
我们以后一律采用微软的AjaxControlToolkit所带的控件，此组控件基本包括了我们所用的所有控件。主要特点是无刷新，用集成性好。
l 通用组件管理
组件管理分为可在任何项目中都可用的组件和本项目可用的组件。这些组件事实就是由各种类组成的程序集。编译好的组件我们引用此DLL文件就可。
任何项目中都可用的组件放在CommonLayer层里。
通用组件的统一管理：通用组件的每个每个方法按标准格式书写，必须提供调用该方法的事例，参数及返回结果。
3 风格设计
l Themes的作用
Themes是Asp.net v2.0的另一个定制Web Site的增强功能，他的作用是可以对页面和控件的一些属性进行设定.并且可以将这些设定应用于整个应用程序、单一页面或者是单一的控件.
主题是一组可视界面设置，包括壁纸、光标、字体、声音和图标。主题是属性设置的集合，使用这些设置可以定义页面和控件的外观，然后在某个Web应用程中的所有页、整个Web应用程序或服务器上的所有Web应用程中一致地应用此外观。
主题由一组元素组成：外观、级联样式表(CSS)、图像和其他资源。主题将至少包含外观。主题是在网站或Web服务器上的特殊目录中定义的。
l Skin的定义
外观文件具有文件扩展名.skin，它包含各个控件(例如，Button、Label、TextBox或Calendar控件)的属性设置。控件外观设置类似于控件标记本身，但只包含您要作为主题的一部分来设置的属性。例如，下面是Button控件的控件外观：
在theme文件夹中创建.skin文件。一个.skin文件可以包含一个或多个控件类型的一个或多个控件外观。可以为每个控件在单独的文件中定义外观，也可以在一个文件中定义所有主题的外观。
有两种类型的控件外观-“默认外观”和“已命名外观”：
当向页应用主题时，默认外观自动应用于同一类型的所有控件。如果控件外观没有SkinID属性，则是默认外观。例如，如果为Calendar控件创建一个默认外观，则该控件外观适用于使用本主题的页面上的所有Calendar控件。(默认外观严格按控件类型来匹配，因此Button控件外观适用于所有Button控件，但不适用于LinkButton控件或从Button对象派生的控件。)
已命名外观是设置了SkinID属性的控件外观。已命名外观不会自动按类型应用于控件。而应当通过设置控件的SkinID属性将已命名外观显式应用于控件。通过创建已命名外观，可以为应用程序中同一控件的不同实例设置不同的外观。
l 级联样式表
主题还可以包含级联样式表(.css文件)。将.css文件放在主题目录中时，样式表自动作为主题的一部分应用。使用文件扩展名.css在主题文件夹中定义样式表。
l 定义ASP.NET主题
1. 在网站上创建名为App_Themes的新文件夹。
2. 注意：该文件夹必须命名为App_Themes。
3. 创建App_Themes文件夹的一个新子文件夹来保存主题文件。该子文件夹的名称就是主题名称。例如，要创建名为BlueTheme的主题，应创建名为\App_Themes\BlueTheme的文件夹。
4. 向新文件夹中添加组成主题的外观、样式表和图像的文件。
l 创建外观
1. 使用.skin扩展名，在主题子文件夹中创建一个新的文本文件。
2. 典型约定是为每个控件创建一个.skin文件，如Button.skin或Calendar.skin。不过，您可以根据自己的需要创建或多或少的.skin文件;外观文件可包含多个外观定义。
3. 在.skin文件中，添加常规控件定义(使用声明性语法)，但仅包含要为主题设置的属性(Property)且不包括ID属性(Attribute)。控件定义必须包含runat="server"属性。
4. 对于要创建的每个控件外观重复步骤2和3。
l 对控件应用外观
主题中定义的外观应用于已应用该主题的应用程序或页中的所有控件实例。在某些情况下，您可能希望对单个控件应用一组特定属性。这可以通过创建命名外观(.skin文件中设置了SkinID属性的一项)，然后按ID将它应用于各个控件来实现。有关创建命名外观的详细信息，请参见如何：定义ASP.NET主题。
对控件应用命名外观
设置控件的SkinID属性，如下面的示例所示：
<asp：calendar id="DatePicker" skinid="SmallCalendar" runat="server">
如果页面主题不包括与SkinID属性匹配的控件外观，则控件使用该控件类型的默认外观。
4 配置管理
采用科学的配置管理思想，辅之以先进的配置管理工具，可以很容易的解决项目开发过程中由于管理上引起的问题。
1. 列出软件开发、运行、维护各阶段所需的软件配置项
所谓软件配置项就是在软件开发工作进展中得到的许多工作产品、阶段产品、使用的工具软件等信息项。表1中列举了若干类软件配置项及其生成的阶段。
表1 软件配置项
分类阶段实例
环境类软件开发环境或软件维护环境编译器、操作系统、编辑器、数据库管理系统、开发工具、项目管理工具、文档编制工具
定义类需求分析与定义阶段结束后得到的工作产品需求规格说明、项目开发计划、设计标准或设计准则、验收测试计划
设计类设计阶段结束后得到的工作产品系统设计规格说明、程序规格说明、数据库设计、编码标准、用户界面标准、测试标准、系统测试计划、用户手册
编码类编码及单元测试结束后得到的工作产品源代码、目标码、单元测试数据及单元测试结果
维护类进入维护阶段以后生成的工作产品以上任何需要变更的软件配置项
只有明确了各阶段有哪些软件配置项，软件企业才能在实施软件配置管理时胸有成竹、游刃有余。
2. 对现有软件配置项进行分类、补充，进一步完善软件配置
软件企业在实施某一软件时，针对不同的用户都有不同的需求。表2是不同用户的工作环境：
表2 工作环境
用户计算机配置操作系统后台数据库系统
用户APIV1.4GWIN2000SQL Server2005
用户BPIV3.5GWIN2000Oracle9.0
为了满足各个用户的使用要求，我们的软件产品必须考虑到这些差异。在产品的设计时我们尽可能的作成3所示的安排：
表3 列表安排
用户配置项(模块)
用户AA模块、b模块、c模块、e模块、h模块
用户BA模块、b模块、c模块、f模块、g模块
为了实现这两种不同的软件配置，在实际开发应用中，我们完全可以将各个配置项分别开发出来，再根据用户的需求，组合成不同的产品，如图1所示：
图1 不同用户组合成不同的产品
3. 对软件项目的变更要实行有效的控制和管理
软件企业在软件的开发、运行、维护过程中必然要遇到软件的变更。引起软件的变更主要有两方面的因素：一方面是用户，如用户要求修改工作范围和需求等;另一方面是软件开发人员自身，如他们在工作中发现前期工作中的错误而修改源码甚至设计。对于以上两种情况软件企业可以从以下几方面加以解决：
明确实施变更的双方人员
事先应该明确用户有权提出需求变更申请的人员和软件企业项目开发组有权受理变更的人员，并且对双方人数要加以控制。这样做的好处是可以约束需求方，使需求方每提一个需求都要经过仔细讨论。而项目开发组收到用户的需求变更时，通过有权实施变更人员讨论后，可以兼顾全局，对涉及到的相关文档、程序、计划都随之变更。
对变更进行严格的审核
并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。比如涉及到界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题。
对变更的影响进行评估
变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让用户了解变更的后果，并与用户一起做判断。
让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请用户一起做判断：“我可以修改，但您能接受后果吗?”，并且对用户一一列出修改的后果。
4、对软件版本进行有效的管理
软件企业开发的软件产品为了适应不同的运行环境、不同的平台、不同用户的使用要求，导致同一软件产生或演化出不同的版本。软件企业可以通过以下两种常用的方法进行软件版本控制。
号码版本标识
以数字表示，如第一版，表示为V1.0。第二版表示为V2.0。一般认为V1.0，V2.0是基础版本号，V1.1、V1.2是对基础版V1.0的第一次修订和第二次修订。显然这些修订都是少量的修改。若有重大变动或因多次修订导致的全局性的重要变动，则应提高版本号，如V2.0。号码版本标识可以如图2所示：
图2 号码版本标识
符号版本标示
这种版本表示法是把版本的重要信息提炼出来。如V1/VMS/DB SERVER，表示一个在VMS操作系统上运行的数据库服务器版本。对于软件企业可以用“人事管理系统单机版”、“人事管理系统网络版”等来表示。
实施有效的配置审核
软件企业在实施配置审核时可以从以下两方面进行：
“配置管理活动审核”
“配置管理活动审核”用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，如检入(Check in)/检出(Check Out)的频度、工作产品成熟度提升原则等。
“基线审核”
要保证基线化软件工作产品的完整性和一致性，并且满足其功能要求。基线的完整性可从以下几个方面考虑：基线库是否包括所有计划纳入的配置项?基线库中配置项自身的内容是否完整?(如，文档中所提到的参考或引用是否存在?)此外，对于代码，要根据代码清单检查是否所有源文件都已存在于基线库。同时，还要编译所有的源文件，检查是否可产生最终产品。一致性主要考察需求与设计以及设计与代码的一致关系，尤其在有变更发生时，要检查所有受影响的部分是否都做了相应的变更。审核发现的不符合项要进行记录，并跟踪直到解决。
在实际操作过程中，一般认为审核是一种事后活动，很容易被忽视。但是“事后”也是有相对性的，在项目初期审核发现的问题，对项目后期工作总是有指导和参考价值的。为了提高审核的效果，应该充分准备好检查单，如表4所示。
表4 检查表
检查表YesNO说明
是否及时Check in与Check out
是否对配置库进行定期备份
是否给配置系统定期病毒检查
上次审核中的不符合项是否已解决
是否进行定期审核工作
是否成立配置审核小组
6、进行配置工具选择
软件企业选择商业配置管理工具，可以考虑下面几个因素。
工具的市场占有率
大家都选择的东西通常会是比较好的东西。而且市场占有率高也通常表明该企业经营状况会好一些，被人收购或者倒闭的可能性小一点。
工具本身的特性
工具本身有稳定性、易用性、安全性、扩展能力等。您应当在投资以前仔细地对工具进行试用和评估。这儿比较容易忽略的是工具的扩展能力(Scalability)，您现在可能只是在几个人、十几个人的团队中部署这个工具，但是以后可能会有几十个、几百个人要在依赖这个工具建立的平台上工作，到时候这个工具能不能提供这样的支持能力?如果到时候要换一个工具的话，您一定会后悔今天的选择。
5 抽象对象模型
抽象对象模型为企业级应用系统提供业务公共平台，把政企应用共有的业务提炼出来，形成通用的业务信息系统，在此层面基础之上，用来构建、集成和运行政府、企业的信息系统，以减少企业级应用开发过程中重复的开发。
基于可重构的抽象对象模型，这些类既包含由应用程序开发人员继承和使用完整方法，也包含可能由应用程序业务对象的开发人员实现的方法的抽象定。应用程序开发人员可使用此对象模型来构建面向对象的应用程序和框架。
抽象对象模型提供下列特性：
² 自定义业务对象属性
² 可变的业务逻辑
² 统一的对象唯一标识符
² 面向对象的设计模式
² 按照对象属性的查询/筛选方案
6 模型驱动
MDA(Model Driven Architecture)是模型驱动架构，它是由OMG定义的一个软件开发框架。它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。和UML相比，MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。MDA把建模语言用作一种编程语言而不仅仅是设计语言。MDA的关键之处是模型在软件开发中扮演了非常重要的角色。
MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，MDA提供了一种途径(通过相关的工具)来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。MDA的三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性。
模型驱动架构(MDA)是OMG组织近年来一直热炒的一个新的技术体系，同时也是众多搞软件模型研究人员的一个新热点。MDA(模型驱动)核心的思路是希望通过对商业模型(比如企业信息化或建筑领域的解决方案)的领域研究。进而提炼出一个相对核心的领域模型，同时抽象出一个PIM(平台无关模型)。之后根据不同的开发平台(例如.net或J2EE)，应用平台(windows或unix)形成相应的PSM(平台相关模型)。依照相应的工具，例如ArcStyler可以完整地生成相应的代码和软件系统。当然这里只是罗列出一个大致的思路和方法。
1. MDA理论还处在一个探索期，很多理论和方法并不成熟，当然无从谈起有成熟的工具，从目前的趋势而言，从理论到实际的工具都离OMG组织所提出的预想有较大距离，至少还需要数年的努力才能成型。
2. 目前无论是国外的开源组织还是国内的一些组织对MDA都只是处在一个草创阶段，很多人所谓的应用MDA其实都只是在MDA的体系中作一个最初的探索和尝试。例如ORM就是在一定层次上实现MDA在数据库应用方面的探索，但也只是解决了一个实体模型映射的问题。前几天一个面试人员用ArcStyler4.X做了一个银行POS系统的应用模型，生成了一点还需要修改的框架代码。就告诉我说他已经掌握了MDA，斯等水准真是让我汗颜!佩服!
3. MDA的第一个热点可能是桥接器，而在MDA领域中，映射是个很重要的点，而转换和交互都只是在这个点上的延伸。
4. 目前而言，最有可能在MDA体系中得以实现的语言是JAVA，尽管我很讨厌JAVA的一些愚蠢方法。
5. MDA的核心是PIM，因为他是最抽象和协同性最高的。同时就当前形势而言，PIM也是一个瓶颈!同时就目前的UML2.0(从OMG那里得到最新的)而言，还不足以作为建立整个MDA体系的语言。同时对于MOF中的一些定义似乎还有提升的必要。因为对于整个体系而言，MOF应该更多的作为一个标准，只有在标准成熟的前提下，才有可能产生正确的映射规则。
6. 等到MDA风光无限的那天，会使一部分程序员失业，但不会是全部，起码MDA工具要有人做，因为一个MDA工具不足以应付所有的领域。这就好比没有一个财务系统能适应所有的企业一样。因为各个领域的标准化不同。
l MDA的流程
MDA的实现主要集中在以下3个步骤：
1. 首先，您用UML对您的应用领域进行高度抽象的建模，这个模型和实现它的技术(或者底层技术)完全没有关系。这个模型我们称之为平台无关模型(PIM)。
2. 然后，PIM将被转换为一个或多个平台相关模型(PSM)。这个翻译的过程一般是自动实现的。PSM将用一个特定的实现技术来描述您的系统。它将用到这种技术所提供的种种架构，比如EJB，数据库模型，COM组件等等。
3. 最后，PSM将被翻译成源代码。因为每个PSM已经完全依靠某种特定的技术，这个步骤一般是比较简单的。
MDA流程中最难的一步，是从PIM生成一个PSM。它要求您对您要应用的基础技术具有丰富且巩固的知识，另一方面，源模型(PIM)必须具备自动生成PSM所要求的足够信息量。
l 通过模板生成：MDA-light?!
在MDA的实际应用当中，一个较容易的实现是通过模板(我们称之为MDA-light)。这样，平台相关模型这一步可以说是被跳过了，您可以直接从高度抽象的PIM生成源代码。您将继续在MDA-light的基础上进行真正意义的编程：您必须在源代码，而不是UML，编写细致的应用逻辑。
l 使用MDA的前提
业界(甚至是整个世界)一个被广泛接受的事实是：只有变化是永恒的。技术永远在革新。这在中间件领域尤其明显，当然还有数据库技术，操作系统，甚至是编程语言都经常变化。这些技术明显比应用领域的基本概念要变化的快。
如果您在某一特定的应用领域工作，在这个领域中的项目都具有一定的相似性。整个应用程序族或者不同的项目都属于同一个应用领域，那么，MDA或者生成流程将特别适合于您。
l MDA的优点
您对建模的投资将更加持久的有效--远长于您目前实现它所应用的技术。这将更有利于保护您的投资。
您具有了技术上的灵活性。
您将不再受技术或应用所具有的不同变化周期的影响--在MDA的帮助下，您可以中立的保持两方面的多样性。
l MDA的缺点
MDA意味着更多的"组装"而不是"开发"--在为一个应用建立PIM的时候，您基本上没有技术上的周旋空间。这对于今天的很多开发人员来说，还是难以想象的。
软件开发的创造性在一定程度上减弱了。开发人员常常觉得，就一种新技术展开争论，在技术的前沿工作，是十分吸引人的。可是在MDA流程下，大量的工作是建立模型，这和具体的技术相距甚远，但符合OMG的建议。
潜在的不成熟性。UML2.0还在幼年时代。MDA工具出现的时间也相对很短。这里还隐藏了很多风险。
l MDA流程和生成开发中有待解决的问题
数据和应用程序的移植：目前在商业领域经常需要面对的问题是，大量的数据和应用程序如何向新的，MDA为基础的系统中移植。纯粹的MDA流程将把数据模型和数据库表结构看成是技术细节。它们不应该对平台无关模型(PIM)层产生任何影响--那么，您的MDA工具或生成器也负责生成数据库脚本吗?
软件维护：编制不同的发行版本，补丁或者升级，是对目前正在运行的程序进行维护的重要组成部分。MDA怎么处理这些问题呢?每次进行一次全新的安装?
投资报酬率(Return-on-Investment)：从什么样的环境和系统开始计算?从应用MDA的第二个项目?还是从第五个开始?
生成器和相关工具造成了对其生产商的依赖--这种对生产商的依赖是我们以往一直极力避免的。
企业应用整合(EAI)：高度的抽象，听起来不错--但是对于已经在运转的应用系统，怎么得到这种抽象呢?
您可以看到--潜在很多实际问题(其回答都具有重要的意义)。这些问题正是我们创立openMDA的原因：在很多项目当中，某些以上的问题已经得到了实验性的回答，您(和我们)都将从中获益!
l MDA的软件开发周期
在MDA中软件开发过程是由软件系统的建模行为驱动的。下面是MDA的软件开发周期：
MDA生命周期和传统生命周期没有大的不同，主要的区别在于开发过程创建的工件，包括PIM(Platform Independent Model，平台无关模型)、PSM(Platform specific Model，平台相关模型)和代码。PIM是具有高抽象层次、独立任何实现技术的模型。PIM被转换为一个或多个PSM。PSM是为某种特定实现技术量身定做。例如，EJB PSM是用EJB结构表达的系统模型。开发的最后一步是把每个PSM变化为代码，PSM同应用技术密切相关。传统的开发过程从模型到模型的变换，或者从模型到代码的变换是手工完成的。但是MDA的变换都是由工具自动完成的。从PIM到PSM，再从PSM到代码都可以由工具实现。PIM，PSM，和Code模型被作为软件开发生命周期中的设计工件，在传统的开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不同的视角来看待我们的系统，将高层次的PIM转换到PSM的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构，而不会被具体的实现技术所“污染”，同时对于复杂系统，也减少了开发人员的工作量。
MDA的出现，为提高软件开发效率，增强软件的可移植性、协同工作能力和可维护性，以及文档编制的便利性指明了解决之道。MDA被面向对象技术界预言为未来两年里最重要的方法学。当今建模的主要问题在于，对于很多企业来说它只是纸面上的练习。这就造成了模型和代码不同步的问题，代码会被不断修改，而模型不会被更新，这样模型就失去了意义。弥补建模和开发之间的鸿沟的关键就在于将建模变为开发的一个必不可少的部分。MDA是模型驱动开发的框架，MDA的愿景是定义一种描述和创建系统的新的途径。MDA使得UML的用途走得更远，而不仅仅是美丽的图画。很多专家预言MDA有可能会带领我们进入软件开发的另一个黄金时代。
l MDA框架
MDA将软件系统的模型分离为平台无关模型PIM和特定平台模型PSM，同时又能通过转换规则将它们统一起来，以这样的方式试图去摆脱需求变更所带来的困境。平台无关模型PIM是对系统高层次的抽象，其中不包括任何与实现技术相关的信息;特定平台模型PSM是特定平台相关的模型。在MDA框架中，首先使用平台无关的建模语言来搭建平台无关的模型PIM，然后根据特定平台和实现语言的映射规则，将PIM转换以生成平台相关的模型PSM，最终生成应用程序代码和测试框架。
MDA框架的“建筑材料”包括：高层次模型;一种或多种标准、精确定义的语言，用来编写高层次模型;如何把PIM变换到PSM的定义;编写这些定义的语言，这种语言能够被变换工具执行;能够执行变换定义的工具;能够执行PSM到代码的变换工具。
上图是MDA的框架，它的主要元素有模型、PIM、PSM、语言、变换、变换定义、以及变换工具。MDA是一个开放的，中立于软件供应商的架构，它广阔地支持不同的应用领域和技术平台，能够成为应用领域和具体技术平台之间的杠杆。在MDA开发途径中，PIM代表对需求的建模，PSM代表应用具体技术后的模型，这使得MDA成为需求和技术之间的杠杆;它们各自的改变都可以是相互独立的，不会造成商业逻辑和实现技术的紧密藕合，同时MDA又可以通过转换来弥补它们之间的鸿沟，从而保护我们的投资。MDA开发途径使得我们的系统能够灵活地被实现、集成、维护和测试，系统的轻便性、互操作性和可重用性都是可以长期保持的，能够应对未来的变化。
l MDA的现状
MDA还处在一个发展的过程中，MDA还在不断的演进。虽然MDA正朝气蓬勃地走来，但是人们也能看出它所存在的问题。MDA最大的好处就是业务模型的持久价值，但是付出的代价是增加了抽象层，而目前看来，层之间的转换并不是我们所期待的那样顺畅，至少，从PIM到PSM，从PSM到代码，这个实现的过程要远比从3GL生成机器代码来得困难。在建模技术方面，UML正在暴露其固有的缺陷，它需要扩展更多的机制来支持精确建模和分析模型，虽然目前OCL为精确建模提供了一定的支持，但是这种支持距离可执行模型的理想还很遥远。回顾MDA的历史，我们可以看出UML的巨大成功为MDA的产生奠定了坚实的基础，同时也感觉到：在由软件工艺到软件工程的漫漫长路中，MDA只不过是向前迈进了一小步，但却给整个软件业掀起了一场波澜，它在模型定义、开发过程等诸多方面都将对未来IT技术产生深远的影响。
目前在MDA开发工具市场上的情形是：由于从PIM到PSM转换方法的标准化尚未完成，IBM、Borland等大型厂商大都持谨慎态度，虽然也纷纷在他们的开发工具中提供部分的MDA功能，但并没有完全遵循OMG定义的MDA规范。虽然如此，IBM除了在Rational中增加MDA功能之外，在开源项目Eclipse中，也提出了EMF(Eclipse Modeling Framework)这一创新的MDA代码生成系统项目，由此可见IBM对MDA这一发展中的技术的重视程度。Borland公司宣称他们也在关注MDA技术，并且准备在Together中配置基于MDA的模型自动生成功能。相对于业界大厂的冷静和矜持，一些中小厂商反而特别活跃，像Interactive Objects公司著名的ArcStyler、Compuware公司著名的OptimalJ，还有开放源码的AndroMDA等遵循OMG标准规范的MDA工具已在一些项目中得到了广泛的运用，并取得了显著的成效。
l MDA的相关标准
为了实现MDA这一宏大构想，OMG制定了一系列的标准：
UML：UML被MDA用来描述各种模型。它并不是为MDA而生，但是作为目前最为风行的建模语言，UML已经占据了全球建模语言领域90%的市场份额，成为了建模语言事实上的标准，因此OMG将它作为MDA技术的基础是自然而然的明智选择。它是MDA的基础，也是MDA最有力的武器。
MOF：MOF(Meta Object Facility元对象机制)是比UML更高层次的抽象，它的目的是为了描述UML的扩展或者其它未来可能出现的类UML的建模语言。虽然MOF也不是为MDA而生的，但是我们可以体味到OMG的工程师们良苦的用心和长远的目光。
XMI：XMI(XML-based metadata Interchange)是基于XML的元数据交换。它通过标准化的XML文档格式和DTDs(Document Type Definitions)为各种模型定义了一种基于XML的数据交换格式。这使得作为最终产品的模型可以在各种不同的工具中传递，这一点是非常重要的，它保证了MDA不会在打破了一种束缚之后再被加上一层新的束缚。
CWM：CWM(Common Warehouse Metamodel公共仓库元模型)提供了一种数据格式变换的手段，在任意级别的模型上都可以使用CWM来描述两种数据模型之间的映射规则，比如将数据实体从关系数据库变换为XML格式。在MOF的框架下，CWM使得通用的数据模型变换引擎成为可能。
在OMG的蓝图中，UML、MOF、XMI、CWM等一系列标准分别解决了MDA的模型建立、模型扩展、模型交换、模型变换这几个方面的问题。OMG试图通过标准化的定义，扩大MDA的应用范围。同时通过这样一个可扩展的建模语言环境，IT厂商可以自由实现自己的建模语言，以及语言到可执行代码的映射，然而不管怎么样，都必须处于OMG的标准化框架之下。