CN102004659A - 集成环境生成器 - Google Patents

Abstract

一种集成环境生成器，接收输入文件并将该输入文件转换为标记语言文件。该输入文件标识待部署应用的模块、模块间依赖关系、用于测试模块的测试用例、以及调度信息。该集成环境生成器接收规则，并参照该规则来验证标记语言文件。该规则规定用于包括输入文件中的模块依赖关系的统一格式。该集成环境生成器从经验证的标记语言文件标识模块、模块间依赖关系、调度信息以及测试用例。该集成环境生成器选择用于模块间的所标识依赖关系的构建脚本模板，用于所标识调度信息的调度脚本模板，以及用于所标识测试用例的测试用例脚本模板；并且根据这些模板生成构建脚本、调度脚本和测试用例脚本。

Description

集成环境生成器

优先权

本申请要求2009年8月31日提交的名称为“Build ScriptGeneration(构建脚本生成)”的美国临时专利申请系列号61/238,379的优先权，在此通过引用并入其全部内容。

技术领域

本申请涉及集成环境生成器以及用于构建脚本的方法和设备。

背景技术

可以是因特网应用、商业应用、最终用户应用等的很多应用包括执行不同功能的多个软件模块。例如，在线购物应用具有用于执行购物车结算功能的多个模块。这些模块可以包括支付模块、验证模块和购物车模块。

为了在计算机系统上部署这些模块，创建这些模块，并将其一起放置在可部署包中。可部署包可以包括用来创建或更新应用的文件集合。文件集合可以包括可执行文件或者向服务器或其他计算机系统上加载的其他信息。当可执行文件被执行时，可以创建或更新包括模块的应用。

在应用部署阶段期间，可部署包被构建多次，并被测试。部署包的构建可能是耗时和复杂的，对于具有多个模块和其他组件的大型应用尤其如此。通常，每当存在应用组件的依赖关系改变或者其他改变时，开发者人工编写或者修改构建脚本。构建脚本标识信息，诸如模块之间的依赖关系，以及用于创建部署包的其他信息。构建脚本继而由传统构建工具用于基于该构建脚本来生成部署包。每当需要创建部署包以进行测试时便人工确定模块间的依赖关系并且创建或修改脚本文件，这倾向于变为劳动力密集型的，并且复杂和易错。

发明内容

按照一个实施方式，一种集成环境生成器，包括：输入转换模块、验证模块、遍历模块、模板选择模块以及文件生成模块。输入转换模块配置用于接收输入文件，并且将输入文件转换为标记语言文件，该输入文件标识待部署应用的模块、模块之间的依赖关系、用于测试该模块的测试用例以及调度信息。验证模块配置用于接收规则，并且参照该规则来验证标记语言文件，该规则规定用于包括输入文件中的模块依赖关系的统一格式。遍历模块配置用于从经验证的标记语言文件标识模块、模块间依赖关系、调度信息以及测试用例。模板选择模块配置用于：选择用于模块间的所标识依赖关系的构建脚本模板，用于所标识调度信息的调度脚本模板，以及用于所标识测试用例的测试用例脚本模板。文件生成模块配置用于根据构建脚本模板来生成构建脚本，根据调度脚本模板来生成调度脚本，以及根据测试脚本模板来生成测试用例脚本。

按照一个实施方式，一种用于生成构建脚本的方法，包括：接收输入文件并将该输入文件转换为标记语言文件，该输入文件标识应用的模块、模块间的依赖关系、用于测试模块的测试用例、以及调度信息。该方法还包括：接收规则，并参照该规则来验证标记语言文件，该规则规定用于包括输入文件中的模块依赖关系的统一格式。该方法还包括：从经验证的标记语言文件标识模块、模块间依赖关系、调度信息以及测试用例；选择用于模块间的所标识依赖关系的构建脚本模板，用于所标识调度信息的调度脚本模板，以及用于所标识测试用例的测试用例脚本模板；以及根据构建脚本模板来生成构建脚本，根据调度脚本模板来生成调度脚本，以及根据测试脚本模板来生成测试用例脚本。按照一个实施方式，上述方法可以在非瞬态计算机可读介质上存储的计算机程序中具体化，当该计算机程序由计算机系统执行时，其执行该方法。

附图说明

将参考以下附图，在下文描述中详述本发明的实施方式。

图1示出了按照一个实施方式的集成环境生成器的系统框图；

图2示出了按照一个实施方式的集成环境生成器的更详细的系统框图；

图3示出了按照一个实施方式的UML设计的示例；

图4示出了按照一个实施方式的树结构的示例；

图5示出了按照一个实施方式的用于生成部署包的方法；以及

图6示出了按照一个实施方式的作为用于在此描述的集成环境生成器的硬件平台而运行的计算机系统。

具体实施方式

出于简便和说明目的，实施方式的原理将主要通过参考其示例来描述。在下文描述中，记载了多个特定细节以提供对实施方式的透彻理解。然而，对于本领域普通技术人员而言易见的是，可以不限于这些特定细节来实践实施方式。在某些情况下，没有详细描述公知的方法和结构以避免不必要地混淆实施方式。而且，在此描述的实施方式可以按照不同的组合彼此结合使用。

1.概述

按照一个实施方式，一种集成环境生成器，配置用于生成用于计算机系统上的应用的可部署包的构建脚本。构建脚本根据输入文件而生成，输入文件包括按照已经参照规则集进行了验证的统一格式表示的信息。输入文件中的信息标识应用模块之间的依赖关系，并且包括创建部署包所需要的其他信息。规则规定关于模块和其他元素的架构性信息，并且用来对输入文件进行验证。集成环境生成器还配置用于生成调度脚本，其指示将在何时以及以何种频度生成构建脚本和部署包。

在应用部署阶段期间，多个软件开发者可以一起工作来创建和测试应用。开发者可以通过使用工具执行各种任务来改善其效率。例如，连续集成是在开发者改变应用代码的同时以固定间隔执行系统构建的过程。通过连续集成的过程，开发者可以确保经改变的应用代码与其他开发者开发的代码兼容。为了确保经改变的代码与其他开发者开发的代码的兼容性，集成环境生成器还生成测试用例脚本，用以测试经改变的应用代码中编码的模块的依赖关系。

由此，集成环境生成器通过以下方式来辅助开发者，即，定期创建构建脚本和调度脚本，从而对应用代码进行编译以及参照应用的其他部分进行定期测试。

2.系统

图1示出了按照一个实施方式的集成环境生成器100。集成环境生成器100接受输入文件101和规则102作为输入。

在一个实施方式中，输入文件101是统一建模语言(UML)文件，然而，其他格式或者语言也可以用于输入文件101。UML是一种标准建模语言，可以用来创建应用的可视模型。输入文件101可以包括UML设计，其提供用来创建应用的信息。UML设计可以标识应用的元素。元素可以包括：商业过程、用户、软件组件、活动，等等。UML设计还标识应用的模块以及模块间的依赖关系。UML设计还包括：指示何时以及以何种频度创建部署包的调度信息，以及用来测试模块间依赖关系的测试用例。

规则102规定关于模块和其他元素的架构性信息，并且用来验证输入文件101。规则102可以规定用于输入文件101中所包括信息的格式或者语法。规则102可以规定：依赖关系应使用特定符号来图绘表示，以及基于其依赖关系的用于提供符号的位置。其他规则102的示例包括：各模块间的依赖关系不应成环；各模块间的依赖关系应是单向的；各模块间的依赖关系应由UML的<<use>>构造型(stereotype)来指定；模块应使用UML组件符号来指定；以及保留应用组件名称中的最后两个字母，并且形成有助于将应用组件向相应模块进行映射的模块缩写。规则102还规定调度要求。例如，通过向构造型<<AbstractCommonLayer>>的属性<<scheduleTimePeriodIn Hours>>赋值来规定调度信息。规则102还规定针对测试用例的要求，包括通过向使用UML符号的每个已建模方法上的属性<<testCaseId>>赋值来规定测试用例。

集成环境生成器100输出构建脚本103、调度脚本104以及测试用例脚本105。构建脚本103是用来构建部署包的脚本。构建脚本标识信息，诸如模块间的依赖关系，以及用于创建部署包的其他信息。例如，构建脚本103由构建工具106用来生成部署包107。构建工具106可以是现成的软件工具。调度脚本104是由集成环境生成100生成的脚本，用以标识何时以及以何种频度生成构建脚本和部署包。例如，调度脚本104可以指示：应当在晚上9点、每6个小时构建部署包，因此对应用代码中编码的模块所做的任何修改将被捕获在日常构建中。测试用例脚本105是对模块间依赖关系进行测试的脚本。测试用例脚本105指示应在特定模块上执行测试，并且还可以指示测试如何链接。

图2示出了集成环境生成器100的更为详细的系统框图。集成环境生成器100包括：输入转换模块200、验证模块201、遍历模块202、记录模块203、模板选择模块204以及文件生成模块205。模块200-205可以是软件模块、硬件或者软件和硬件的组合。

输入转换模块200接受输入文件102，作为对集成环境生成器100的输入。如上所述，输入文件101可以包括UML设计，其提供用来创建应用的信息。UML设计可以标识应用的元素。元素可以包括：商业过程、用户、软件组件、活动，等等。UML设计还标识将要构建或更新和部署的应用的模块，以及模块间的依赖关系。输入文件101中的UML设计被保存为UML元模型。UML元模型是表示应用元素的数据模型。为了进一步处理输入文件101的UML设计，输入转换模块200可以使用传统的工具和技术，将UML设计的UML元模型转换为XML文件210或者其他标记语言文件。

验证模块210接受规则102，作为对集成环境生成器100的输入。如上所述，规则102可以规定关于模块和其他元素的架构性信息。例如，规则102可以规定用于输入文件101中所包括信息的格式或语法。验证模块102还从输入转换模块200接收XML文件210。验证模块201参照规则102来验证XML文件210。验证模块201确保XML文件210符合规则102。规则102的示例包括：各模块间的依赖关系不应成环；各模块间的依赖关系应是单向的；各模块间的依赖关系应由UML的<<use>>构造型来指定；模块应使用UML组件符号来指定；以及保留应用组件名称中的最后两个字母，并且形成有助于将应用组件向相应模块进行映射的模块缩写。模块102还规定调度要求和测试用例要求。

遍历模块202遍历XML文件210，以便从经验证的XML文件210标识模块、模块间依赖关系以及调度信息和测试用例。可以对经验证的XML文件210进行解析，以标识此信息。

记录模块203将从XML文件210标识的模块、模块间依赖关系、调度信息和测试用例的指示存储在已提取信息数据库206或者其他数据存储中。在将信息存储在例如已提取信息数据库206中时，将模块间依赖关系、调度信息和测试用例与从中标识它们的XML文件210相关联。

基于存储的在模块间标识的依赖关系，记录模块203还生成树结构，以便按照机器可理解的格式来反映模块间依赖关系。树结构也与从中标识模块间依赖关系的XML文件210相联系地存储在已提取信息数据库206中。

模板选择模块204标识用于存储在已提取信息数据库206中的模块间依赖关系、调度信息和测试用例的多个模板的模板。该多个模板是可定制的，并且是特定于软件架构的。该多个模板具有指定结构的占位符。存在三类模板，包括构建脚本模板、调度脚本模板以及测试用例脚本模板。当然，可以存在更多类型的模板。构建脚本模板用来创建构建脚本103。调度脚本模板用来创建调度脚本104，并且测试用例脚本模板用来创建测试用例脚本105。

模板选择模块204从已提取信息数据库206中获取XML文件210的信息。基于获取的信息，模板选择模块204选择要填入的多个模板的模板。例如，在将输入文件101转换为XML文件210时，与该XML文件对应的模块间依赖关系、调度信息和测试用例被保存在已提取信息数据库206中。一旦获取了模块间依赖关系、调度信息和测试用例，模板选择模块204便选择用于所获取的依赖关系的构建脚本模板。模板选择模块204还选择用于调度信息的调度脚本模板，以及用于测试用例的测试用例脚本模板。模板选择模块204利用获取的模块间依赖关系来填入构建脚本模板，利用调度信息来填入调度脚本模板，并且利用测试用例来填入测试用例脚本模板。例如，利用实际的UML元素属性来替换模板中的占位符。

文件生成模块205分别基于构建脚本模板、调度脚本模板和测试用例脚本模板，生成包括构建脚本103、调度脚本104和测试用例脚本105的输出文件。

部署包构建工具(未示出)使用脚本来创建部署包，该部署包继而在计算机系统上部署。部署包构建工具可以是用于创建部署包的传统、现成的构建工具。3.示例

图3示出了按照一个实施方式的UML设计的示例。如上所述，参考图1，输入文件101可以是统一建模语言(UML)文件。输入文件101可以包括UML设计300，其提供用来创建应用的信息。UML设计300可以标识应用的元素。元素可以包括：商业过程、用户、软件组件、活动，等等。在图3中，四个模块301-304由UML中的<<component>>构造型标识。模块301名为“信用卡授权模块(CreditCardAuthorizationModule)”，模块302名为“安全管理(SecurityManagement)”，模块303名为“用户管理(UserManagement)”，并且模块304名为“银行账户管理(BankAccountManagement)”。

UML设计300还通过<<use>>构造型来标识模块301-304间的依赖关系。例如，模块301依赖于模块302、303和304，这由<<use>>构造型302a、303a和304a以及箭头的方向性示出。此外，模块302和304依赖于模块303，如<<use>>构造型303b和303c以及箭头的方向性所示。

图4示出了反映图3中模块301-304的依赖关系的树结构400。如上所述，基于存储的在模块301-304间标识的依赖关系，生成树结构400，以便以机器可理解的格式来反映模块的依赖关系。

4.方法

图5示出了按照一个实施方式的方法500。方法500和在此描述的其他步骤在此可以关于图1和图2以示例而非限制的方式加以描述。

在步骤501，集成环境生成器100接收输入文件，例如输入文件101。如上所述，输入文件可以包括UML设计，其提供用来创建应用的信息。UML设计可以标识应用的元素。元素可以包括：商业过程、用户、软件组件、活动，等等。UML设计还标识应用的模块以及模块间的依赖关系。输入文件中的UML设计被保存为UML元模型。UML元模型是表示应用元素的数据模型。

而且，在步骤501，集成环境生成器100接收规则，例如规则102，作为对集成环境生成器100的另一输入。如上所述，规则规定关于模块和其他元素的架构性信息。

在步骤502，集成环境生成器100将UML设计转换为XML文件。输入文件中的UML设计被保存为UML元模型。UML元模型是表示应用元素的数据模型。使用传统工具和技术将UML元模型转换为XML文件。可以使用其他格式来替代XML。而且，可以将其他格式用于输入文件来替代UML。如果输入文件以XML提供，则不执行步骤502。

在步骤503，集成环境生成器100参照规则来验证在步骤501创建的XML文件，以确保XML文件符合规则。

在步骤504，集成环境生成器100遍历XML文件，并且从经验证的XML文件标识模块、模块间依赖关系、调度信息以及测试用例。例如，对经验证XML文件进行解析，以标识模块、模块间依赖关系、调度信息以及测试用例。

在步骤505，集成环境生成器100将从XML文件标识的模块、模块间依赖关系、调度信息和测试用例的指示存储在已提取信息数据库或者其他数据存储中。模块间依赖关系、调度信息和测试用例与从中标识它们的XML文件相联系地存储。

在步骤506，基于存储的在模块间标识的依赖关系，生成树结构以反映模块的依赖关系。树结构也与从中标识模块间依赖关系的XML文件相关地存储在已提取信息数据库中。

在步骤507，集成环境生成器100标识用于存储在已提取信息数据库中的模块间依赖关系、调度信息和测试用例的多个模板的模板。该多个模板可以包括构建脚本模板、调度脚本模板以及测试用例脚本模板。构建脚本模板用来创建构建脚本。调度脚本模板用来创建调度脚本。测试用例脚本模板用来创建测试用例脚本。从已提取信息数据库获取XML文件的信息。基于获取的信息，选择要填入的多个模板的模板。例如，在将输入文件转换为XML文件时，与该XML文件对应的模块间依赖关系、调度信息和测试用例被保存在已提取信息数据库中。一旦获取了模块间依赖关系、调度信息和测试用例，便针对所获取的模块间依赖关系来选择构建脚本模板。集成环境生成器100还选择用于调度信息的调度脚本模板，以及用于测试用例的测试用例脚本模板。继而利用获取的模块间依赖关系来填入构建脚本模板，利用调度信息来填入调度脚本模板，并且利用测试用例来填入测试用例脚本模板。

在步骤508，集成环境生成器100分别基于构建脚本模板、调度脚本模板和测试用例脚本模板，生成包括构建脚本、调度脚本和测试用例脚本的输出文件。

在步骤509，部署包构建工具使用脚本来创建部署包，该部署包继而在计算机上部署。部署包构建工具可以是用于创建部署包的传统、现成的构建工具。

5.计算机系统

图6示出了可以用作集成环境生成器100的硬件平台的计算机系统600。计算机系统600可以用作用于执行一个或多个在此描述的方法、功能和步骤的平台，这些步骤可以具体化为存储在一个或多个非瞬态计算机可读介质(诸如，存储设备)上的软件。

计算机系统600包括处理器602或者可以实现或者执行软件指令的处理电路，该软件指令执行某些或全部在此描述的方法、功能和其他步骤。来自处理器602的命令和数据通过通信总线604传送。计算机600还包括：非瞬态计算机可读存储设备603，诸如随机访问存储器(RAM)，用于处理器602的软件和数据在运行时期间可以驻留在此。存储设备603还可以包括非易失性数据存储。计算机系统600可以包括用于连接网络的网络接口605。对于本领域的技术人员易见的是，可以在计算机系统600中添加或替换其他已知的电子部件。

尽管已经参考示例描述了实施方式，但是本领域的技术人员将能够在不脱离要求保护的实施方式的范围的情况下，对所描述的实施方式进行各种修改。而且，在此描述的实施方式可以用来创建用于诸如实时环境的任何环境的脚本。

Claims (20)

1.一种集成环境生成器，包括：

输入转换模块，配置用于接收输入文件，并且将所述输入文件转换为标记语言文件，所述输入文件标识待部署应用的模块、所述模块间的依赖关系、用于测试所述模块的测试用例以及调度信息；

验证模块，配置用于接收规则，并且参照所述规则来验证所述标记语言文件，所述规则规定用于包括所述输入文件中的所述模块的所述依赖关系的统一格式；

遍历模块，配置用于从经验证的标记语言文件标识所述模块、所述模块间的所述依赖关系、所述调度信息以及所述测试用例；

模板选择模块，配置用于选择用于模块间的所标识依赖关系的构建脚本模板、用于所标识调度信息的调度脚本模板、以及用于所标识测试用例的测试用例脚本模板；以及

文件生成模块，在计算机系统上执行并配置用于根据所述构建脚本模板来生成构建脚本，根据所述调度脚本模板来生成调度脚本，以及根据所述测试脚本模板来生成测试用例脚本。

2.如权利要求1所述的集成环境生成器，还包括：记录模块，配置用于生成反映所述模块间的所述依赖关系的树结构。

3.如权利要求1所述的集成环境生成器，其中所述标记语言文件是XML文件。

4.如权利要求1所述的集成环境生成器，其中所述构建脚本用来创建可部署包。

5.如权利要求1所述的集成环境生成器，其中所述输入文件包括统一建模语言(UML)设计。

6.如权利要求1所述的集成环境生成器，其中所述规则包括规定各模块间的所述依赖关系不应成环的规则。

7.如权利要求1所述的集成环境生成器，其中所述规则包括规定各模块间的所述依赖关系应由统一建模语言(UML)的<<use>>构造型来指定的规则。

8.一种用于生成构建脚本的方法，所述方法包括：

将输入文件转换为标记语言文件，所述输入文件标识应用的模块、所述模块间的依赖关系、用于测试所述模块的测试用例以及调度信息；

参照规则来验证所述标记语言文件，所述规则规定用于包括所述输入文件中的所述模块的所述依赖关系的统一格式；

从经验证的标记语言文件标识所述模块、所述模块间的所述依赖关系、所述调度信息以及所述测试用例；

选择用于模块间的所标识依赖关系的构建脚本模板、用于所标识调度信息的调度脚本模板、以及用于所标识测试用例的测试用例脚本模板；以及

根据所述构建脚本模板来生成构建脚本，根据所述调度脚本模板来生成调度脚本，以及根据所述测试脚本模板来生成测试用例脚本。

9.如权利要求8所述的方法，还包括：

生成反映所述模块间的所述依赖关系的树结构。

10.如权利要求8所述的方法，其中所述标记语言文件是XML文件。

11.如权利要求8所述的方法，其中所述构建脚本用来创建可部署包。

12.如权利要求8所述的方法，其中所述输入文件包括统一建模语言(UML)设计。

13.如权利要求8所述的方法，其中所述规则包括规定各模块间的所述依赖关系不应成环的规则。

14.如权利要求8所述的方法，其中所述规则包括规定各模块间的所述依赖关系应由统一建模语言(UML)的<<use>>构造型来指定的规则。

15.一种用于生成构建脚本的设备，所述设备包括：

用于将输入文件转换为标记语言文件的装置，所述输入文件标识应用的模块、所述模块间的依赖关系、用于测试所述模块的测试用例以及调度信息；

用于参照规则来验证所述标记语言文件的装置，所述规则规定用于包括所述输入文件中的所述模块的所述依赖关系的统一格式；

用于从经验证的标记语言文件标识所述模块、所述模块间的所述依赖关系、所述调度信息以及所述测试用例的装置；

用于选择用于模块间的所标识依赖关系的构建脚本模板、用于所标识调度信息的调度脚本模板、以及用于所标识测试用例的测试用例脚本模板的装置；以及

用于根据所述构建脚本模板来生成构建脚本、根据所述调度脚本模板来生成调度脚本、以及根据所述测试脚本模板来生成测试用例脚本的装置。

16.如权利要求15所述的设备，还包括：

用于生成反映所述模块间的所述依赖关系的树结构的装置。

17.如权利要求15所述的设备，其中所述标记语言文件是XML文件。

18.如权利要求15所述的设备，其中所述构建脚本用来创建可部署包。

19.如权利要求15所述的设备，其中所述输入文件包括统一建模语言(UML)设计。

20.如权利要求15所述的设备，其中所述规则包括规定各模块间的所述依赖关系不应成环的规则。

Images