一种基于模板的模型驱动软件开发方法和系统

摘要

本发明提供了一种基于模板的模型驱动软件开发方法，包括：选择目标平台并读取模型文件；根据选择的目标平台和所述模型文件的类别，读取对应的模板；根据所读取的模板将模型文件转换成物理工件。还提供了基于模板的模型驱动软件开发系统，包括：模板库，用于存储模板，所述模板上具有转化模型元素为物理工件的指令；平台选择模块，用于选择目标平台；生成器，用于根据平台选择模块选择的目标平台和模型文件的类别读取模板库中对应的模板，并根据读取的模板上的指令将模型文件转化为物理工件和代码文件目录。本发明可以实现基于模板将模型文件转化为物理工件。

说明书

技术领域

本发明涉及一种软件开发技术领域，特别是指一种基于模板的模型驱动的软件开发方法和系统。

背景技术

软件开发通常以创建逻辑模型开始，常见于企业软件领域的各种逻辑模型已经很好的被统一建模语言(UML，Unified ModelingLanguage)所揭示，如实体模型，流程模型，状态模型，又如其他一些UML所忽略但实际上非常重要的模型，如用户界面和交互模型，业务规则模型，组织模型等等。这些模型刻画了待开发软件的功能性需求。

OMG组织的MDA架构(Model Driven Architecture)提出了平台无关的模型(PIM，Platform Independent Model)和平台相关的模型(PSM，Platform Specific Model)，但如何满足企业软件的非功能性需求则语蔫不详。

为了帮助软件开发者并使软件开发流程中尽可能多的开发步骤自动化，出现了产生式编程技术(Generative Programming)，基于该技术的进一步发展则是偏向代码生成的模型驱动开发(ModelDriven Development)技术。

而对于模型驱动软件开发技术来说，尚没有关于可以将逻辑模型转化成满足非功能性需求的物理工件的方法。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于模板的模型驱动软件开发方法，以实现基于模板将模型文件转化为物理工件。

对于上述技术问题，本发明是这样加以解决的。基于模板的模型驱动软件开发方法，包括：

B、选择目标平台并读取模型文件；

C、根据选择的目标平台和所述模型文件的类别，读取对应的模板；

D、根据所读取的模板将模型文件转换成物理工件。

由上可以看出，利用模板上的细节将模型文件，经由上述步骤将转化成为在目标平台上可以执行的物理工件。利用模板的可复用性，可以对同一目标平台下的所有该类模型文件进行转换。从而提高了企业软件的非功能性需求的自动转换生成的程度。降低了软件开发的工作量。

优选的是，所述步骤D包括：

D1、解析模型文件生成模型元素；

D2、为模型文件加载所读取的模板，所述模板上具有转化模型元素为物理工件的指令；

D3、根据模板上的所述指令将模型元素转换为物理工件。

由上可以看出，模型文件中包含了大量的业务信息，即模型元素。对于每个模型元素来说，其处理的方式是不一样的。为了将模型元素有效的转化成物理工件，则需要将模型文件解析成模型元素，再用模板上的指令将模型元素转化成目标平台上可执行的物理工件。

优选的是，所述指令包括至少以下之一：

文本指令、分支指令、循环指令和赋值指令。

由上可以看出，每个物理工件，包括所有的软件都是由最基本的四种语句组成的，即顺序语句、分支语句、循环语句和赋值语句。对应的，模板上对模型元素的处理就包括：文本指令、分支指令、循环指令和赋值指令。基于这四个指令可以有效的将模型元素转换成物理工件。

优选的是，所述步骤B前还包括：

A1、导入解决方案；

A2、解析所导入的解决方案生成模型文件目录和对应的模型文件；

步骤B中读取模型文件为：根据所述模型文件目录读取对应的模型文件；

所述步骤D后还包括，编译生成的物理工件。

由上可以看出，通常来说，单个与领域模型对应的模型文件并不足以完整的描述整个欲开发软件的所有信息，需要多个不同的模型文件相互组合成解决方案。通过上述步骤可以实现整个解决方案到物理工件的转换。

优选的是，所述模型文件包括至少以下之一：

用来描述各个业务实体的业务实体类模型文件、用来描述业务操作的业务操作类模型文件、用来描述服务的服务项目类模型文件、用来描述向用户所显示界面信息的用户接口类模型文件、用来描述业务处理过程的业务流程类模型文件、用来描述报表功能的业务报表类模型文件。

由上可以看出，目前一个软件包含的业务信息主要可以由一个或多个上述六类模型文件对应的领域模型描述。

本发明还提供了一种基于模板的模型驱动软件开发系统，其特征在于，包括：

模板库808，用于存储模板，所述模板上具有转化模型元素为物理工件的指令；

平台选择模块806，用于选择目标平台；

生成器810，用于根据平台选择模块806选择的目标平台和模型文件的类别读取模板库808中对应的模板，并根据读取的模板上的指令将模型文件转化为物理工件。

由上可以看出，利用该系统可以为读取的模型文件加载对应的模板，从而转换为物理工件了。

优选的是，所述生成器810包括：

模型文件读取模块81002，用于读取模型文件；

模板读取模块81004，用于根据平台选择模块806选择的目标平台和模型文件读取模块81002读取的模型文件，读取模板库808中的对应的模板；

模型文件解析模块81006，用于解析模型文件生成模型元素；

指令模块81008，用于根据所述模板上的指令将模型元素转换成物理工件；

由上可以将模型文件解析成模型元素，再用模板上的指令将模型元素转化成目标平台上可执行的物理工件。

优选的是，所述指令模块81008包括，

文本模块810082，用于处理模板上的文本指令，根据文本指令将模型元素转换成物理工件；分支模块810084，用于处理模板上的分支指令，根据分支指令将模型元素转换成物理工件；赋值模块810086，用于处理模板上的赋值指令，根据赋值指令将模型元素转换成物理工件；循环模块810088，用于处理模板上的循环指令，根据循环指令将模型元素转换成物理工件。通过该指令模块81008所包含的四个指令模块可以有效的将模型元素转换成物理工件。

优选的是，还包括，

解决方案导入模块802，用于导入解决方案；

解决方案解析模块804，用于解析解决方案生成模型文件和模型文件目录；

编译模块814，用于编译所生成的物理工件。

修改模块812，用于修改所生成的物理工件。

由上可以实现导入解决方案，实现整个解决方案到物理工件的转换。

其中，模板库808包括至少以下之一：业务实体类模板80802、业务操作类模板80804、服务项目类模板80806、用户接口类模板80808、业务流程类模板80810、业务报表类模板80812。

由上，软件包含的业务信息可以由一个或多个上述六类模板对应的领域模型进行描述。

附图说明

图1为基于模板的模型驱动软件开发方法的流程图；

图2为解决方案构成示意图；

图3为解决方案“在线电子商城”解析后生成的模型文件目录和模型文件的示意图；

图4为解决方案“在线电子商城”中的业务实体类模型文件解析后生成的代码文件目录和模型元素的示意图；

图5为建立代码文件目录并生成物理工件的流程图；

图6为在保护区中修改的示例图；

图7为建立解决方案的流程图；

图8为基于模板的模型驱动软件开发的系统的结构示意图；

图9为模板库中的模板结构示意图；

图10为对应于六类领域模型的模板库的示意图；

图11为解决方案解析模块的结构示意图；

图12为生成器的结构示意图；

图13为指令模块的结构示意图；

图14为设计领域模型的流程示意图；

图15为根据解决方案完成系统开发示意图。

具体实施方式

针对领域模型需要产生的不同的物理工件，需提供单独的模板和模板集合，模板提供了怎样把领域模型的元素转换为相关的物理工件元素的指令。下面结合附图对基于模板的模型驱动软件开发方法进行详细描述。

如图1所示为基于模板的模型驱动软件开发方法的流程图，包括以下步骤：

步骤102，导入解决方案。

解决方案是开发人员针对要开发的系统所建立的，参见图2示出的解决方案构成示意图，解决方案通常由以下六类模型文件中的一类或几类组成：业务实体类模型文件、业务操作类模型文件、服务项目类模型文件、用户接口类模型文件、业务流程类模型文件和业务报表类模型文件。每类模型文件包含了一个或多个模型文件。

其中，业务实体类模型文件用来描述各个业务实体。业务操作类模型文件用来描述业务操作。服务项目类模型文件用来描述服务。服务定义为一段独立的逻辑程序，当多个服务组合在一起时可完成不同类型的业务需求。用户接口类模型文件用来描述向用户所显示的界面信息。业务流程类模型文件用来描述业务处理过程。例如一个订单处理工作流组件可能结合客户、订单等业务实体对象完成订单处理的工作流程。业务报表类模型文件用来描述报表功能。

解决方案所包含的模型文件是根据建立解决方案时所设计的领域模型生成的。其中，所述领域模型是指对企业模型的结构化和抽象化，将技术实现与领域业务相分离，并且将对象模型的行为和数据相融合的技术。对于根据领域模型生成模型文件，即建立解决方案的步骤将在后文参见图7进行简述。

以“在线电子商城”为例，下面对解决方案进行举例，该例中，解决方案采用的是XML语言进行封装和传输：

 <？xml version＝”1.0”？>

 <Solution Name＝”在线电子商城”>

   <BEProject File＝”Ecommerce.beprj”/>

   <BPProject File＝”Ecommerce.bpprj”/>

   <ServiceProject File＝”Ecommerce.svcprj”/>

   <UIProj ect File＝”Ecommerce.uiprj”/>

   <WorkflowProject File＝”Ecommerce.flowprj”/>

</Solution>

由上可见，在这个针对“在线电子商城”的示例性解决方案中，包括了一个业务实体模型文件Ecommerce.beprj，一个业务操作模型文件Ecommerce.bpprj，一个服务模型文件Ecommerce.svcprj，一个用户接口模型文件Ecommerce.uiprj，以及一个业务流程模型文件Ecommerce.flowprj。

对于各个模型文件的具体内容，由领域模型生成，且设计者可以在一个集成环境中，例如可以通过可视化编程界面，同时编辑修改这些模型文件。可参见如图14所示的设计领域模型的流程示意图。

步骤104，解析解决方案，生成模型文件目录和模型文件。

通常对于一个解决方案下的各类模型文件来说，每类模型文件由一个或多个模型文件组成。这些模型文件之间的关系由开发人员指定。对应的，解析解决方案时会将解决方案根据其组成生成模型文件目录和模型文件。如图3所示为解决方案解析后生成的模型文件目录和模型文件的示意图。

仍以“在线电子商城”为例，下面对解析生成的模型文件进行举例。首先下面列出的程序代码为解析生成的业务实体模型文件Ecommerce.beprj的示例：

 <？xml version＝”1.0”？>

 <BEProject Name＝”在线电子商城”>

   <Class Name＝”订单”>

     <Reference Name＝”客户”/>

     <Field Name＝”下单时间”Type＝”DateTime”/>

      …

   </Class>

   <Class Name＝”客户”>

     <Field Name＝”姓”Type＝”String”/>

     <Field Name＝”名”Type＝”String”/>

     …

  </Class>

</BEProject>

该例中，解析解决方案生成的业务实体模型文件其中包括两个业务实体，订单业务实体和客户业务实体。订单业务实体包括订单号、下单的客户、下单时间等属性。客户实体包括客户编号、客户的姓名等属性。其中，模型文件中包含的类似于这些属性的具有业务意义的信息称为模型元素。

下面列出的程序代码为解析生成的业务操作模型文件Ecommerce.bpprj的示例：

BP Project文件：

<？xml version＝”1.0”？>

<BPProject Name＝”在线电子商城”>

  <Operation Name＝”提交订单”>

    <Param Name＝”客户名”Type＝”String”/>

    <Param Name＝”单据号”Type＝”String”/>

 </Operation>

  …

</BPProject>

解析解决方案生成的业务操作模型文件描述了业务操作，该例中，包含了一个关键的业务操作，即用户提交订单的业务操作，该业务操作描述了用户点提交订单按钮后系统应该做什么，例如检查用户的合法性、检查产品有无库存、多少天能够出货、如何计价等。

下面列出的程序代码为解析生成的用户接口模型文件Ecommerce.uiprj的示例：

UIProject文件：

<？xml version＝”1.0”？>

<UIMLProject Name＝”在线电子商城”>

  <UIML Name＝”产品浏览”>

    <Panel>

      <TextBox Name＝”search”Text＝”Search！”/>

      <Grid>

        <Column Name＝”产品名”/>

        <Column Name＝”单价”/>

         …

      </Grid>

   </Panel>

 </UIML>

 <UIML Name＝”购物车”>

   <Panel>

     <Button Name＝”提交订单”/>

     ....

   </Panel>

  </UIML>

</UIMLProject>

解析解决方案生成的用户接口模型文件描述了与用户的接口，即界面信息。本例中的用户接口模型文件包含了两个界面，一个是产品目录和列表，在该界面上显示包括产品名，每种产品的简要介绍，报价等信息；另一个是购物车管理，在该界面上显示包括所购产品，总价，折扣、提交订单等信息。其中，各个界面所使用的控件、位置、排列方式、字体和颜色等信息，也在模型文件中进行描述。

以上仅列举了几种解析后生成的模型文件。针对不同的业务的解决方案，解析所述解决方案生成不同的模型文件，由这些模型文件描述了各种业务内容，即模型元素。

步骤106，选择目标平台。

选择所要生成的物理工件的目标平台。例如C#、Java或者C++等。

仍以“在线电子商城”为例，下面对C#的目标平台文件进行举例：

BE：Order.cs

using System；

using System.Collections；

namespace ADIFU.Ecommerce

{

public class Order

{

   private Customer customer；

   private DateTime orderDate；

   public Customer Customer

   {

      get

      {

          return customer；

      }

      set

      {

         customer＝value；

      }

    }

    public DateTime OrderDate

    {

       get

       {

          return orderDate；

       }

       set

       {

          orderDate＝value；

       }

     }

   }

}

步骤108，根据模型文件的类别选择对应类别的模板。

模板提供了将模型元素转换为相关的物理工件的指令。如图9所示为模板的结构示意图。所述物理工件可以是一个代码段或者一个可执行程序等。

仍以“在线电子商城”为例，下面对对应于实体类模型文件的模板进行举例。其模板名“BE.cs.tpl”中的BE即对应于实体类模型文件：

BE.cs.tpl：

using System；

using System.Collections；

namespace#{namespace}

{

  public class#{be.Name}

  {

     <！foreach field in be.Fields>

     private#{filed.Type}#{lower(field.Name)}；

     </！foreach>

     <！foreach field in be.Fields>

     public#{filed.Type}#{field.Name}

     {

      get

      {

           return#{lower(field.Name)}；

      }

      set

      {

           #{lower(field.Name)}＝value；

      }

    }

    </！foreach>

…

    }

}

其中，每个目标平台对应了一系列的模板。同一目标平台下的每类模型文件通常对应了一个模板。从而对于新建的解决方案可以复用以前的模板，以有效的降低开发工作量。

步骤110，根据所读取的模板将模型文件转换成物理工件。

模板提供了将模型元素转化为物理工件的指令。加载模板后首先模型文件被解析成一个或多个模型元素。再按照模板提供的指令，对应的将模型元素转化成物理工件。

如果一个模型文件对应生成的物理工件很多的话，还可以用代码文件目录来描述物理工件之间的关系。如图4所示为解决方案“在线电子商城”中的业务实体类模型文件1解析后生成的代码文件目录和模型元素的示意图。代码文件目录和模型文件目录一样，也可以由开发人员在建立解决方案的时候指定。

设计者大部分的工作是在用IDE建模，在可视建模的过程中IDE隐式的不断建立模型文件目录和模型文件，而代码目录是在设计者点击“生成”按钮后，由生成器在一个生成过程中一次性建立的。

如图5所示为建立代码文件目录并生成物理工件的流程图。在下文对图5的说明中会对步骤110进行详细描述。

步骤112，在保护区修改物理工件。

对于未能定义完整的软件产品的每个细节的领域模型，可以通过在产生的物理工件中进行编程，从而完成未定义部分。本实施例中提供一种保护区域机制，在受保护区中，开发者可以直接书写受保护而免于进行转换的程序代码。保护区中的手工输入代码的修改独立于领域模型的变更。故即使模型迭代地演进，保护区中的代码仍留在相同的逻辑位置中。如图6所示为在保护区中修改的示例。

步骤114，编译生成的物理工件。例如对于C#可以在Visual Studio2005平台中进行编译，对于Java可以在JDK平台中编译。

至此，完成了由解决方案生成物理工件的整个过程，如图15所示为开发的示意图。根据开发人员建立的解决方案，只需要复用模板即可得到目标平台上的物理工件。从而大大提高了软件开发的效率。

下面结合图5对步骤110建立代码文件目录和生成物理工件的过程进行详细说明，包括以下步骤：

步骤502，读取模型文件。例如对于“在线电子商城”可以按照图3所示的模型文件目录依次读取模型文件。

步骤504，解析模型文件得到模型元素。如图4所示，解析模型文件中的业务信息生成对应的模型元素。以步骤104中的“在线电子商城”的业务实体类模型文件的示例为例。其解析后生成2个模型元素，即订单业务实体和客户业务实体。

步骤506，加载模板。根据模型文件的类别分别加载对应类别的模板。同一类别的模型文件加载的是同一模板。例如图3所示解决方案“在线电子商城”中包括2个业务实体类模型文件。它们对应于C#目标平台加载的是步骤108中示出的业务实体类模板。

步骤508，建立代码文件目录。如图4所示为解决方案“在线电子商城”中的业务实体类模型文件1解析后生成的代码文件目录和模型元素的示意图。

步骤510，生成物理工件。根据模板上的指令将模型元素转换成物理工件。

以步骤108示出的“在线电子商城”的业务实体类模板(BP)为例。当加载这段模板的时候，根据文本指令判断，没有#{}和<！></！>特殊控制符的都视为普通文本，原封不动的输出；根据赋值指令对于#{}则取得里面的变量值然后输出该值；对于<！>相关的控制指令，若是if else语句则根据分支指令，进行分支判断，然后对求值为真的分支继续模板处理逻辑，若是foreach语句则根据循环指令循环其内部的模板处理逻辑。

步骤512，输出物理工件。

由此完成了模型文件转换成物理工件的步骤。

对于步骤102描述的解决方案，即根据领域模型生成模型文件为现有技术，下面参见图7所示的解决方案生成的流程图，对为建立解决方案的步骤仅进行简述，包括以下步骤：

步骤702，新定义一个解决方案。仍以“在线电子商城”为例，新定义一个名为“在线电子商城”的解决方案。

步骤704，新定义至少一类领域模型。为名为“在线电子商城”的解决方案定义各类领域模型。例如名为“订单业务”的业务实体类领域模型等。

步骤706，对应领域模型绘制输入相应的模型元素。例如在业务实体类领域模型中输入“客户”的模型元素，包括“客户名”等。

步骤708，生成模型文件。本实施例中，采用的是XML语言。不难理解，也可以采用其它类似的语言进行模型文件的封装也是可以的。

步骤710，将多个模型文件组合成生成解决方案。

至此就完成了解决方案的生成过程。

下面结合附图对基于模板的模型驱动软件开发的系统进行详细描述。

如图8所示为基于模板的模型驱动软件开发的系统800的结构示意图，包括：

解决方案导入模块802，用于导入解决方案。如图2所示为解决方案构成示意图，此处不再重复描述。

解决方案解析模块804，用于解析解决方案，生成模型文件和模型文件目录。下文会结合图11进行详细描述。

模板库808，用于存储模板，所述模板上具有转化模型元素为物理工件的指令。如图9为模板库中各个模板的模板结构900，包括文本指令902、分支指令904、循环指令906和赋值指令908四种。每个模板具有这四种指令中的一种或多种指令。

本实施例中，模板库中对应于每个目标平台，分别各有一套模板。每套模板通常对应于不同的模板种类，例如图10所述的模板库包含了常用的六类模板，为：用来处理业务实体类模型文件的业务实体类模板80802、用来处理业务操作类模型文件的业务操作类模板80804、用来处理服务项目类模型文件的服务项目类模板80806、用来处理用户接口类模型文件的用户接口类模板80808、用来处理业务流程类模型文件的业务流程类模板80810和用来处理业务报表类模型文件的业务报表类模板80812。

平台选择模块806，用于选择目标平台。例如C#、Java或者C++等。

生成器810，用于根据平台选择模块806选择的目标平台和模型文件的类别读取模板库808中对应的模板，并根据读取的模板上的指令将模型文件转化为物理工件和代码文件目录。下文会结合图12对生成器810进行详细说明。

修改模块812，用于在保护区内修改生成的物理工件。

编译模块814，用于将生成的物理工件进行编译处理。

由此利用基于模板的模型驱动软件开发的系统800就可以将导入的解决方案生成为物理工件了。

下面结合图11对解决方案解析模块进行详细说明。如图11所示解决方案解析模块804包括：模型文件生成模块8042，用于生成模型文件；模型文件目录生成模块8044，用于生成模型文件目录。如图3为解决方案“在线电子商城”解析后生成的模型文件目录和模型文件的示意图。

由此将解决方案解析成了模型文件和模型文件目录。

下面结合图12对生成器810进行详细说明。如图12所示生成器810包括：

模型文件读取模块81002，用于读取模型文件。

模板读取模块81004，用于根据平台选择模块806选择的目标平台和模型文件读取模块81002读取的模型文件，读取模板库808中的对应的模板；例如为目标平台为C#的解决方案200中的业务实体类模型文件2002，读取的是模板库808中的业务实体类模板。

模型文件解析模块81006，用于解析模型文件，生成模型元素。如图4所示为解决方案“在线电子商城”中的业务实体类模型文件1解析后生成的代码文件目录和模型元素的示意图。

指令模块81008，用于根据模板具有的指令将模型元素转换成物理工件；如图13所示，其包括：

文本模块810082，用于处理文本指令；根据模板中的文本指令将模型元素内的内容作为普通文本输出，进而转换成物理工件。

分支模块810084，用于处理分支指令；根据模板中的分支指令将模型元素内的内容进行分支判断，然后对求值为真的分支继续模板处理逻辑，进而转换成物理工件。

赋值模块810086，用于处理赋值指令；根据模板中的赋值指令将模型元素里面的变量值取值后输出该值，进而转换成物理工件。

循环模块810088，用于处理循环指令。根据模板中的循环指令循环处理模型元素，进而转换成物理工件。

代码文件目录生成模块81010，用于生成如图4所示的代码文件目录。

物理工件输出模块81012，用于输出生成的物理工件。

由上可以看出，通过本发明，就可以基于模板将模型文件转化为物理工件，实现将逻辑模型转化成满足非功能性需求的物理工件。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。