这将我们带入到模型驱动开发的另一个主要用途，把系统和软件开发更多地纳入到系统和软件工程规则中。模型驱动开发是关于开发和维护系统的，系统并不只是由应用程序组成，还包括其他的部分，使得人们可以理解这个应用程序。一个模型可以包含明显可执行的部分，但它几乎总是还有其他部分，并不能被运行，比如需求，系统的粗略框架，商业模型和分析模型。在项目开发时，所有这些都应该被创建出来并保持最新，它们对于将来的维护非常重要。
模型驱动开发的现代工具提供了运行一个（或部分）模型的能力，这使得可以更早得到确认，系统能按预定方式工作。换句话说，这意味着项目风险被极大地降低。在模型驱动开发中，测试也变得更加重要，因为能够被更早和更频繁地进行。这种方式，会使你对在项目后期，应用程序的各部分能够统一合作具有更多地信心。直观地，你可能以为所有这些额外的工作会延长开发周期，但是经验显示，产品上市时间实际上是缩短了。你花费更少的时间用于实现和测试阶段，更多的时间用于分析和设计阶段，当你迭代重复这些过程时，你会发现，这种方式的好处是实实在在的。
UML 2.0 的作用
无疑，统一建模语言（UML，Unifid Modeling Language）就是设计用来进行模型驱动开发的语言。它第一次标准化是在1997 年，作为当时各种面向对象分析方法之争的结果。然后它迅速成为最流行的建模语言，用于“可视化、构造和存档在基于软件的系统创建过程中的产品”。
我们沿着这条道路已经走了五年，用户和工具提供商对于UML 语言都有了更多的经验。我们知道什么很有用处，也知道什么需要被改进。而且，软件工业在这些年也发生了变化，需要去支持一些新的技术，比如基于构件的开发和可执行的模型。这些需求还不能用现在的UML 合适地处理。为了解决这些问题，对UML 大的修订工作两年前由OMG 开始启动，预计于2002 年底前完成。
在语言中新增加的性能，用于对系统架构建模，都是些很重要的部分，使得更容易创建任何复杂度的实际系统。对这种规模可伸缩性的关注也扩展到了其他领域，包括对行为进行建模的图形，比如顺序图和状态机。既然UML 试图适合很多参与方的需要，它需要变成一种相当大的语言，但是并不是每一个人都需要知道语言的所有部分。它被有意识地分割成几种视图或图形，允许你关注于只与你相关的专门领域。其他人可能希望工作在其他的视图上，模型将保持这些视图间的一致性。
工具的考虑
工具实现模型驱动开发的方式各不相同，给予用户或多或少的灵活性。双向工程是一个可怜人的选择，他不能在模型中捕获到系统行为，并且他还把自己与某种特定的编程语言绑定在一起，这还是一种以代码为中心的方法，所有这些都将使你感到难受。在一些紧急的场合，你甚至会忘记模型，比如一个项目就要到达最后期限（看起来在某处总有一个最后期限）了。在项目的最后，你得到了一个可工作的应用程序，还有一个没有实际用处的模型。这时，你甚至怀疑建模的重要性了。
对双向工程问题的一个让步就是在模型中直接插入编程代码，因此强迫你更新模型以确保最终得到一个可执行的应用程序。这同样使你感到难受，又被绑定到某种特定编程语言，你还不得不在模型的很多地方插入代码片断。这很像在C 程序中插入汇编代码，尽管有时这是必要的，但是将来维护会是问题并可能伤害你。
考虑直接在模型中提供指定系统行为的能力，上述两种方法都变得过时。在模型驱动开发中，你只需按一个键，在你选择的平台上，就能获得自动生成的任何语言的代码，这样在模型这一级上就能实现应用程序的可移植性。你不需要修改代码，改变你的系统就能直接反应到模型的实现上。当然，目前还有一些路需要走，大部分的工具厂商目前都有他们自己的语言映射，但要实现MDA 的目标，就需要有对不同语言和平台的标准映射和脚本。好消息就是这种前景正在展现。模型驱动开发确实正在起作用，并必将改变我们开发系统的方式。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
