【模型驱动软件设计】「过程和工程」版本化

    在软件开发项目中,有效的版本化和配置管理总是非常重要的。

一、版本化的概念

    在MDSD项目中,必须管理和版本化如下方面:

  • 生成工具。当前,这些工具自身仍然在不断开发中,因此,对它们进行版本控制非常有意义。
  • 生成器配置:域体系结构的生成部分,这包括DSL/配置文件定义、元模型、模版和转换。
  • 域体系结构的非生成部分:MDSD平台。
  • 应用程序自身:模型、规范和手工开发的代码。

   在理想情况下,生成的代码没有被版本化,因为在任何给定时间都可以从模型中重新产生该代码,并且因此不会组成真正的程序源代码。当然,这种思想只有在文件系统中从结构上分离手工创建的代码和生成的代码时才可以切合实际地应用。

       模型驱动开发的一个目标是基于相同的域体系结构开发一些应用程序。因此,必要的情况是从应用程序中完全分离平台和生成器配置。

二、项目和相关性

  重点是管理各种项目的相关性,包括它们的版本。对于应用程序项目,有必要指定项目根据域体系结构的哪个版本。如果底层的平台改进了,可能需要同时改进域体系结构并且甚至可能会改进应用程序项目。框架比喻可用于证明这一点:将域体系结构设想为框架。如果改进框架,则需要改变它的客户端应用程序。这些事相同的相关性,因此在域体系结构的改进中应用相同的方法。

三、应用程序项目的结构

项目、工件和存储库

       上图显示了如何在最高级别中建立应用程序项目,以及生成器和编译器如何利用它。

     应用程序的模型,以及手工创建的代码,位于应用程序存储库中。生成器创建由生成器配置支持的生成代码,包括配置文件等。配置文件位于域体系结构存储库中。接下来在构建脚本的帮助下生成应用程序。这个步骤将使用应用程序和平台的手工创建代码,从域体系结构存储库中获得平台的手工创建代码。

四、混合文件的版本管理和构建过程

         完全分离生成代码和非生成代码并不总是可能的或切实可行的。相关示例包括:

  • J2EE部署描述符中的自定义代码;
  • JSP文件中的自定义代码;
  • 属性文件或其他配置文件中的自定义代码。

      在一般情况下,这些是目标语言不提供充分委托机制的位置。

      显而易见的是,这种受保护区域的使用会导致产生在其中混合生成代码和非生成代码的文件。这儿的问题是这些文件通常只可以作为整体版本化。这就导致将登记多余的代码,因为生成的代码毕竟不是来源--来源将是从中生成代码的模型。

     这些多余的代码可导致团队开发期间的不一致性。这种不一致性将随着团队发展状态而成为越来越严重的问题。

      开发者之间的合并冲突专门使用存储库中的应用程序源来检测。

      应该再次强调的是,根据我们的观点,生成代码和非生成代码之间的分离是更可取的方法,并且应该在任何情况下尝试这种方法。

五、团队中的建模和部分模型的版本化

      大型系统必须进行分区。它们的组成部分或子系统在彼此之间或多或少无关的情况下进行开发。接口定义了系统将如何交互。常规的集成步骤是将各部分集合在一起。如果在不同的位置或由不同的团队开发各部分,这种方法就特别有用。当然,这主要会影响开发过程和团队中的通信,或许也会影响系统体系结构。

1.分区与子域

     首先,需要重点指出分区和子域使用之间的区别

子域是隔离整个系统的各个方面。每个子域有它自己的元模型和DSL。不同的元模型通过网关元类在概念上统一。在企业系统的环境中,这些可能是子域业务过程、持久性和GUI。

相反,分区描述部分系统的定义。出于有效项目组织或复杂性的原因,将大量技术上类似的需求分解为可以使用接口集成的单独部分。

2.各种生成的软件体系结构

      如果不同生成体系结构用于项目的不同分区中,将会引发生成的工件是否会协同工作的问题。一般来说,这意味着集成应该发生在生成代码级别上。作为示例,假设利用不同版本的生成基础结构,所有这些基础结构将会创建综合性J2EE应用程序的各个部分。

3.DSL的发展

      DSL一般会在一个项目的过程中持续开发。随着域的相关知识和理解不断增长和深入,DSL将会不断发展。为了使工作更为简单,必须确保DSL在其发展期间保持向后兼容性。

4.分区和集成

    假设不同的团队需要相同的接口,或许是因为一个团队实现了某个组件,该组件使用来自于另一个团队的代码。

     当要做的工作是模型驱动时,需要强制至少在两个模型中具有接口的模型。然而,这种方法并不理想,因为要在两个模型中复制信息,这涉及到一致性的问题。根据工具的不同,存在其他的选择。

1).模型中的集成

      如果建模工具支持,应该确保接口只存在于一个位置中,并且从两个模型中进行引用。从生成器的角度来看,这将产生一个一致的模型。

     是否可以实现这种方法取决于建模工具。在UML工具中,支持分不熟建模的、以存储库为基础的工具是最理想的选择。

2).生成器中通过模型同步的集成

      如果建模工具没有提供适当的集成选择,集成也可以发生在生成器级别上。生成器读取一些输入模型,每个噢行包含特定的模型元素。

     在这种情况下,生成器的任务是解决可能存在的一致性问题。

3).生成器中通过引用的集成

     进一步的集成可选方法是使用引用。

猜你喜欢

转载自blog.csdn.net/zhb15810357012/article/details/131273081