【IT168 技术文档】

  为什么建模？

  如果工具支持的模型不能反应代码以及其他的实现产品，那么这些工具很快就会被摒弃。如果工具支持的模型用于生成代码，那么当开发人员根据生成的代码增添其他代码时，工具通常不能与之同步。尽管这些工具为生成的代码提供了很好的“往返行程”，但最终开发人员还是身陷于解决此类问题的错综复杂的情况中。因为CASE工具试图以超高级别的抽象（与底层实现平台相对）进行操作，所以这些问题经常变得更糟。这会导致生成大量代码，由于混合了手写代码和生成的代码，因此要解决这些问题更加困难。

  尽管存在这些问题，但是与某些软件开发过程有关的一个观点是 - 应用建模可以让开发更轻松。我们的目标是改变开发人员看待建模价值的方式。要将他们的观点（建模是一个在真正开始开发之前不太重要的有用活动）改变为承认建模是一个重要的、主要的开发任务，并且不是主要集中于文档的活动。当将模型视为首要的开发产品时，由于可以使用更强大的应用程序抽象，因此开发人员会编写更少的常规代码。模型驱动的开发也因此顺理成章地更加高效和灵活。此外，其他涉及到的开发人员（从业务分析师、架构师、设计师到网络的用户以及系统管理专业人员）会发现建模对其所负责的任务会产生增值。当模型以这种方式横跨开发和运行时活动时，人员之间的交流可以得到优化，且可跟踪性使得能够跨越生命周期的任何阶段。我们坚信，以这种方式确立建模的主要位置，最终可以改变软件开发的经济性，并且保证软件系统能够满足业务的需要。该模型驱动开发的方法由 Microsoft 创新，是名为软件工厂 的产品的一部分。

  如何在模型驱动的开发中使用DSL？

  通过采纳基于下列想法的模型驱动开发实现：

  ·模型应该是项目中首要的产品 - 不仅仅是一些快过时的文档。模型有精确的语法，通常利用图形化工具易于进行编辑和浏览，并且包含确定模型中特定于域的概念如何映射到其他实现产品的语义，这些实现产品包括代码、项目结构和配置文件等。按照这种方法，模型非常类似于源代码文件，而且它与其他实现产品同步的机制非常类似于编译器。

  ·模型表示一组抽象，它以定义完善的开发内容为开发人员提供支持。例如，考虑这样一个任务：生成一个通过 Web 服务与组件进行连接的、面向服务的应用程序。要构建这样一个应用程序，假设给定开发人员必须关注的所有其他任务，在这种情况下，根据服务合同和开发人员之间交流的信息，该开发人员可以只关注定义整个应用程序连接性。为软件架构师的应用程序设计器提供的 Visual Studio Team Edition 完全支持开发的个各个方面，并管理应用程序连接性模型和所有其他产品（WSDL 文件、项目文件、代码文件、配置文件等）之间的关系。必须开发这些产品以实现由模型定义的互联。按照这种方式设计作为源产品的模型，具有额外的好处 - 提供对其他分散细节的整体视角，并且能够让不同团队（包括设计、构建和部署复杂、现代化应用程序）之间的沟通更加顺畅。

  ·由于模型能够提炼并聚合大量产品中的信息，因此它们能够更轻松地支持一致性检查和其他形式的分析。例如，一个应用程序连接模型可以支持协定协议验证、安全性分析或性能分析。

  ·通过一个与编辑类似的过程可以实现模型，在该过程中，由编译器生成的代码、配置文件和其他实现产品均不能进行手工编辑。然而，较普遍的情况是，模型可以由生成产品和手工编辑产品的组合实现。在这种情况下，非常重要的一点是，仔细管理使生成和手工编辑产品相互适应的方法。如上所述，不能有效做到这一点是 CASE 产品的一个主要不足之处。我们已经使用了一些技术来确保生成的产品和手工编辑产品保持独立，并且当生成工具需要套用代码时，决不会与由开发人员添加的代码发生冲突。这些技术包括，使用类委托和继承，特别是使用“部分类” - 它是 Visual Studio 中 .NET 语言的一个新特性，利用成形的任务已经进行了特别定义。