过去的30年，文档是软件开发过程中的重要容器。所有项目的结构和逻辑最终都是生成了文档和目录。围绕着软件开发的许多工具也是基于这样的概念构建的；编译器、连接器、甚至机器代码都是以代码文档作为输入的。版本控制系统反映出了文档系统结构，保存了每项文档每个版本的一个副本。近十年来，这已经被人们接受，并且已经成为标准。诸如C之类的语言在源代码中通过包含指令被构建与文件参考之上。
问题
在二十世纪九十年代中期，面向对象的软件开发开始成为主导观念。从前很少研究的诸如C＋＋之类的语言， 现在成为主流。随着这个基本原则的变化，基于文档系统的开发最为遗留被延续下来。C＋＋像它的前辈一样，用文件包含解决从属问题。尽管有了诸如UML之类用于建模和设计的新技术、新语言，但最终源文件还是需要被创建并彼此连接。
这种联接导致了一个努力方向：模型必须能被翻译成文档和源代码。复杂构造的原稿必须被写为确保能构造正确的应用的形式。模型发生变化，源代码也必须能被更新反应这种变化；反过来，源代码发生变化，模型也要被更新。
许多各异的软件解决方案用于同步这些各异的文档，但是他们始终都是基于这样的基础观念的：文档是输出产品的重要单元。这也证明了在一个小组环境中文档管理是一个挑战。如果许多开发者从源码控制器中将一个文件迁出，那么版本控制系统必须要确保不发生更改冲突。如果冲突发生，就需要手动干涉解决分歧。由于源码控制系统以文件作为单元控制系统，因此受到了限制。源码控制系统对于包含在文件中语言结构一无所知。
很显然，对软件开发来说，文档是一个超过其用途的遗留物。
模型驱动架构
在2001年末，一个软件开发的新的方法学开始崭露头角，那就是：模型驱动架构（MDA）。MDA的基本原理是：模型并非代码成为中心焦点。
与平台无关的模型由UML构建，然后经过各种各样的转化，最终成为某种特定平台的源代码。很显然，模型而不是文档成为输出产品的重要单元。一种模型对于不同水平的提取有着不同的观点。在最高水平上，与平台无关的组件能够被解析成不同规格；在最低水平上，存在一个依赖于特定平台的执行，它由一系列代码类组成的。
可用的模型符号涉及到了所有能够代替文件的必要特征的定义。具体来说，类间的依赖被容易的通过关联箭头来标记。创建模型的支持工具在理想情况下应该为每个模型元素考虑版本控制问题。每个元素应该有被从库中迁入或迁出的能力。
同样的，模型工具应该和库一起提供元素级别的分支和合并功能支持。例如：开发者应该能够联接库获得一个能迎合需求的元素列表。接着，开发者能够把库中元素分离将其包含在一个新模型中。最后，另一些开发者能够调整不同模型中分支元素的差异。开发环境应该支持这些。
一个普通例子对于这种功能用于Bug的修正。如果在一个项目中，模型元素的bug被修正，那么运用相同模型元素的另一个项目也要反映这种变化。完成这个任务非常简单。
解决方案
这些问题的解决方案可以说是一个完全的范例变化。开发工具必须支持在代码已经产生情况下的变化，并且必须完全支持MDA开发。
显然，代码实际上就是另外一种模型。这种观点以一种与语言无关的代码文档对象模型（CodeDOM）的存在为例证。当你基于这种观点考虑，源代码和UML类只不过是对于相同基础数据的不同视图。他们之间的所有区别都是需要被排除的人为的构造。开发者应该能够用UML创建类及类的属性方法，并能将UML和源代码紧密结合。源代码应该可以同时被多种语言实现。
如今通过CodeDOM使得这些成为可能，CodeDOM本质上是一个易于映射为UML的面向对象的模型。代码结构在大多.NET支持的语言中移植，工具本身就支持这种移植。一个必须被排除的人造物品就是源代码文件。这成为MDA的一项功能，并且没有比MDA更好的方法了。
为了代替源文件，IDE可以直接与项目库联接。项目将直接列出对象，符合文档需求。这种新功能与目前Visual Studio中的类视图一样，视图可以被嵌套的命名空间而不是命名目录所组织，也可以被类、structs、资源而不是文件所组织。当开发者双击这个类时，代码在编辑器中打开。
类视图还包含了UML图。图可以以一定的层次在任何地方创建，开发者可以将类拖拽到设计表面。每个命名空间都有一个默认的图形和若干个附加图形，用于显示系统各个不同的部分。除了代码视图外，工具还应该有类和类关联的绘制视图。理想情况下，代码不应该以任何特定语言的形式存储，而应该存储为附加的CodeDOM结构模型。
对CodeDOM 类较为次要的一点是：它能够用各种语言表达，除去一些对语言细节代码片断的需求。模型中的每种方法都包含语言独立的CodeDOM构造，为了易于编辑，这种构造可以被转化为任何一种支持的语言。正如在FrontPage中存在设计分割视图和HTML视图，开发环境也应该提供一个模型和代码的分割视图。
当基于文件的开发被基于模型的开发所代替，一个新世界被开辟。与其说直接通过创建Web页设计Web站点，还不如说通过构建行为图模仿用户与站点的交互。除编辑之外，工具因该能够产生必要的输出文件以支持这些图形。图中的每个行为都需要一个用户接口，因此包含一个UI设计。例如：对于一些给定的行为，一个Web UI设计和Windows UI设计成为行为的一部分。工具能够允许HTML文件的导入/导出，并给予设计者用自己的工具而不是默认IDE的能力。当设计完成后，HTML文件被导回变成行为。
这个整体观念符合一种新的被称之为"Whitehorse"的技术，Microsoft正将此技术包含在Visual Studio 2005中。Visual Studio 2005还包含对Microsoft的Dynamic Systems Initiative（DSI）的支持，这将通过一个能创建System Definition Model (SDM) 硬件联接组件的工具来实现。Whitehorse包括一系列的新设计，它支持被称之为软件工厂[JG04]的MDA。一个UML类设计器可用于源代码、逻辑应用和基础构造设计，并允许开发者在早期的设计过程中声明应用组件的结构、构造和配置。正如现在的代码文件，这些模型在目前的解决方案中被存储为文件。所有的模型因该存储在库中，并直接通过APIs从库中访问模型。
源码控制系统因该能识别模型和代码中呈现的内部结构，也应该能支持功能级模型元素的迁入和迁出。这种方式下，两个开发者能够工作在一个类的不同部分，并且不存在事后还需协调两部分的潜在问题。建造工具同时也需要支持这种新环境。与其说是文件的编译，还不如说其真正的工作是模型编译。通过一个配置模型，类可以被联接，集成并执行。编译器因该兼顾配置模型，以决定企业类和资源的物理分割，同时也要兼顾类间的依赖，以分解符号。构建过程将输出多种不同的基于需求的文件。对于一个Web项目，ASPX或ASMX页面将随着二进制汇编被创建。
构建过程读取SDM并产生相应的设置文件，并为引入到开发工具中导出SDM。为了达到兼容性目的，工具允许以任何支持的语言抽取并导入源代码文件。开发者可以选择一系列的类，并将其导出，同时工具可以产生必要的文件。然后开发者可以修改这些文件，并把这些文件导回项目中。工具可以自动产生模型元素，如果需要还将提示调整变化。
结论
模型开发环境并没有充分迎合面向对象的变化。所有工具还是依靠文件作为源代码的容器。与一些容纳模型的能力一样，对于文档和代码来说，模型作为不同的实体而存在。
这些工具需要继续发展，以支持模型软件开发；它们需要将模型视图和代码视图融合成一个单一的实体。这听上去像一个根本的改变，但是实际上，新工具对于开发者是自然的结果。
开发者期望他们的类被命名空间组织。他们不用担心哪个文件哪个目录包含哪些代码。如果开发者改变一个方法，他希望能找到所有的该方法的参数，并改变它们。架构师已经构建了软件和系统的模型。因此开发者可以理解这些模型。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/