CN105630553B - 一种产品加载方法及系统 - Google Patents

Abstract

本申请一种产品加载方法及系统，在加载目标产品时，将获取该目标产品的各子系统配置信息，当验证各子系统配置信息中包含有远程子系统引用信息时，由于该远程子系统引用信息能够表明目标产品的相应功能点的功能配置文件和/或菜单配置文件从哪个原有产品即源产品获得，因此，本申请将利用该远程子系统引用信息，获取该源产品的相应功能点对应的源子系统注册文件，以实现与该源产品的数据共享，并利用目标产品的各子系统配置信息以及获得的目标子系统注册文件，确定目标产品的显示界面上各功能菜单的显示内容并输出，无需再在该目标产品的发布目录下重新加载相同的子系统配置信息，就能够直接利用源产品的功能，从而避免了物理空间的浪费。

Description

一种产品加载方法及系统

技术领域

本申请主要涉及电子信息应用领域，更具体地说是涉及一种产品加载方法及系统。

背景技术

产品开发是指个人、科研机构、企业、学校等，创造性研制新产品，或者是对原有产品的改良。如在企业中，产品开发通常是选择能够顺应并满足客户需求的产品样式、同时又能够为企业带来收益和利润的产品进行不断开发。

其中，在企业为客户定制一款产品后，为了满足市场发展的需要，通常会再发布一款不改变原产品的结构，而利用原有产品的业务功能的新产品，与原产品相比，该新产品通常都是在原产品的基础上，重新开发新的业务功能并重新包装，同时能够与原产品实现数据共享。

然而，对于现有的上述新产品的开发过程，申请人发现，其开发的与原产品相同的业务功能通常多会安装到不同的物理目录下，使得该新产品具有多份相同的业务功能，加载该新产品后，将会在该新产品物理目录下再次存储该相同业务功能的相关信息，从而造成了物理空间的浪费。

发明内容

有鉴于此，本发明提供了一种产品系统结构的构建方法及系统，解决了现有技术中开发新产品需要将创建的新的业务功能及其组件信息，与源产品的功能组件信息重新包装，导致该新产品具有多个相同功能组件信息，增大了对物理空间的占用，且因该相同功能组件信息的存储目录不同，而导致新产品与源产品之间的数据同步的实现非常困难。

为了实现上述目的，本申请提供了以下技术方案：

一种软件产品加载方法，所述方法包括：

获取已构建的目标产品的各子系统配置信息，所述子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件；

验证所述各子系统配置信息中是否包含有远程子系统引用信息，所述远程子系统引用信息用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品；

若是，基于所述远程子系统引用信息，获取所述源产品的所述相应功能点对应的源子系统注册文件；

利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出。

优选的，所述目标产品的发布目录与所述源产品的发布目录不同。

优选的，按照以下方式构建所述目标产品：

获取当前已有产品的系统结构及其各子系统配置信息；

以所述当前已有产品的系统结构为基础，当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内时，将能够满足所述当前功能需求的当前已有产品作为所述当前功能需求对应的源产品，并生成所述当前功能需求对应的远程子系统引用信息；

在所述当前功能需求不在所述当前已有产品的系统结构内时，在所述目标产品的发布目录下，创建相应的子系统配置信息。

优选的，在所述当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内具体为：获取的目标产品的当前功能需求的目标功能配置文件在所述当前已有产品的系统结构内，而所述当前功能需求中与所述目标功能配置文件对应的目标菜单配置文件不在所述当前已有产品的系统结构内时，所述生成所述当前功能需求对应的远程子系统引用信息具体为：

生成所述当前功能需求中的目标功能配置文件对应的远程子系统引用信息；

相应的，所述方法还包括：

在所述目标产品的发布目录下，创建所述目标菜单配置文件，并将所述目标菜单配置文件与所述远程子系统引用信息关联。

优选的，所述方法还包括：

获取针对目标产品的显示界面的操作请求，所述操作请求用于表明用户在所述显示界面上选择的目标功能点；

利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单。

优选的，所述利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单包括：

验证所述目标产品的各子系统配置信息中是否包含所述目标功能点的功能配置文件及其对应的菜单配置文件；

若所述各子系统配置信息中包含所述目标功能点的功能配置文件及其对应的菜单配置文件，利用所述菜单配置文件显示所述目标功能点的功能菜单；

若所述各子系统配置信息中不包含所述目标功能点的功能配置文件，而包含所述目标功能点的菜单配置文件，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品获取所述目标功能点的功能配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单；

若所述各子系统配置信息中不包含所述目标功能点的功能配置文件及其菜单配置文件，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品的各子系统配置文件中获取所述目标功能点的功能配置文件及其菜单配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。

一种软件产品加载系统，所述系统包括：

第一获取模块，用于获取已构建的目标产品的各子系统配置信息，所述子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件；

验证模块，用于验证所述各子系统配置信息中是否包含有远程子系统引用信息，所述远程子系统引用信息用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品；

第二获取模块，用于在所述验证模块的验证结果为是时，基于所述远程子系统引用信息，获取所述源产品的所述相应功能点对应的源子系统注册文件；

界面输出模块，用于利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出。

优选的，所述系统还包括：

第三获取模块，用于获取当前已有产品的系统结构及其各子系统配置信息；

引用信息生成模块，用于以所述当前已有产品的系统结构为基础，当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内时，将能够满足所述当前功能需求的当前已有产品作为所述当前功能需求对应的源产品，并生成所述当前功能需求对应的远程子系统引用信息；

信息创建模块，用于在所述当前功能需求不在所述当前已有产品的系统结构内时，在所述目标产品的发布目录下，创建相应的子系统配置信息，其中，所述目标产品的发布目录不同于所述源产品的发布目录。

优选的，所述系统还包括：

第四获取模块，用于获取针对目标产品的显示界面的操作请求，所述操作请求用于表明用户在所述显示界面上选择的目标功能点；

显示模块，用于利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单。

优选的，所述显示模块包括：

验证单元，用于验证所述目标产品的各子系统配置信息中是否包含所述目标功能点的功能配置文件及其对应的菜单配置文件；

第一显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中包含所述目标功能点的功能配置文件及其对应的菜单配置文件时，利用所述菜单配置文件显示所述目标功能点的功能菜单；

第二显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中不包含所述目标功能点的功能配置文件，而包含所述目标功能点的菜单配置文件时，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品获取所述目标功能点的功能配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单；

第三显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中不包含所述目标功能点的功能配置文件及其菜单配置文件时，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品的各子系统配置文件中获取所述目标功能点的功能配置文件及其菜单配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。

由此可见，与现有技术相比，本申请提供了一种产品加载方法及系统。在加载一个新的产品即目标产品时，将获取该目标产品的各子系统配置信息，该子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件，当验证所述各子系统配置信息中包含有远程子系统引用信息，由于该远程子系统引用信息能够表明所述目标产品的相应功能点的功能配置文件和/或菜单配置文件从哪个原有产品即源产品获得。所以，本申请将利用该远程子系统引用信息，获取该源产品的该相应功能点对应的源子系统注册文件，以实现与该源产品的数据共享。之后，即可利用所述目标产品的各子系统配置信息以及获取的所述目标子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出，无需再在该目标产品的发布目录下重新加载相同的子系统配置信息，就能够直接利用该源产品的功能，从而避免了物理空间的浪费。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请提供的一种软件产品加载方法实施例的流程示意图；

图2为本申请提供的另一种软件产品加载方法实施例的部分流程示意图；

图3为本申请提供的一种软件产品系统架构示意图；

图4为本申请提供的一种软件产品创建示意图；

图5为本申请提供的一种软件产品加载系统实施例的结构示意图；

图6为本申请提供的另一种软件产品加载系统实施例的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请提供了一种软件产品加载方法及系统，在加载一个新的产品即目标产品时，将获取该目标产品的各子系统配置信息，该子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件，当验证所述各子系统配置信息中包含有远程子系统引用信息时，由于该远程子系统引用信息用于表明所述目标产品的相应功能点的功能配置文件和/或菜单配置文件是从哪个原有产品即源产品获得。所以，本申请将基于所述远程子系统引用信息，获取该源产品的这些相应功能点对应的源子系统注册文件，以实现与该源产品的数据共享，之后，即可利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出，无需再在该目标产品的发布目录下重新加载相同的子系统配置信息，就能够直接利用源产品的功能，从而避免了物理空间的浪费。

为了使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

如图1所示，为本申请提供的一种软件产品加载方法实施例的流程示意图，该方法可以包括：

步骤S110：获取已构建的目标产品的各子系统配置信息。

在本实施例中，所开发的产品通常都会包含有多个子系统，如企业报税产品，通常都会包含若干个税务业务系统，如税务申报、税务认证、抄报税务、票据打印等等，对于每个税务业务系统来说，其能够实现的各种功能以及实现各功能的菜单界面通常都是不同的，所以说，每个子系统都有自身的配置信息，即该子系统配置信息可以包括当前子系统的注册文件、功能配置文件以及菜单配置文件，但并不局限于此，还可以包括网络信息配置文件、提示信息配置文件、帮助配置文件等等，具体可根据该子系统功能特点及其实际需要确定，本申请对此不作限定。

其中，各子系统的注册文件用于对相应子系统进行注册，确定该子系统的功能模块及该子系统的相关信息，如该子系统的名称、产品编号、版本号、功能模块信息等等，具体可根据实际需要确定，本申请对此不作限定。

另外，上述功能配置文件可以用来配置对应子系统的功能、业务逻辑等等，菜单配置文件可以用于配置对应子系统的对应功能的操作界面。本申请对其包含的具体参数内容不做限定，可根据实际需要确定。

可选的，本申请仅以一个典型子系统注册文件引用信息配置结构为例，来说明产品的子系统注册文件，但并不局限于此。

其中，上述举例的子系统注册文件中，<MODULE>之前部分为该子系统注册相关信息，而<MODULE>这部分为该子系统注册文件中物理模块相关配置信息。

步骤S120：验证所述各子系统配置信息中是否包含有远程子系统引用信息，若是，执行步骤S130，若否，执行步骤S150。

在实际应用中，当开发新产品时，通常都是在原有的产品基础上进行深入开发，甚至有时在发布一款产品时，为了满足市场需要，还需要在开发另一款通过对发布的这款产品的扩展得到的新的产品，该新产品通常就有原来产品的部分或全部功能。

这种情况下，为了简化开发步骤，避免同一配置信息对物理空间的重复占用，本实施例将会在不改变原有的产品结构的基础上，只开发原来产品不具有的功能及其对应的功能配置文件和菜单配置文件，或者原来产品不具有的菜单显示界面的菜单配置文件，而对于和原来产品相同的功能和/或其菜单显示界面，只要创建对应的远程子系统引用信息，以便在用户通过该新产品实现该功能时，直接引用源产品(即原来的产品的一种)的该功能的功能配置文件和/或菜单配置文件来实现该功能，不需要再在该新的产品中重新开发该功能的功能配置文件及其菜单配置。

由此可见，上述远程子系统引用信息可以用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品，以使新产品系统能够根据该远程子系统引用信息查找到能够满足当前功能需求的源产品。

基于上述子系统注册文件引用信息配置结构实例，对于本实施例中包含远程子系统引用信息的子系统配置信息的结构可以为：

其中，上述配置信息中，<REMOTESUBAPP>部分即为远程子系统引用信息，也就是说，上述信息表明目标产品的子系统注册文件中增加了需要引用源产品的相应功能的远程子系统注册文件的引用信息，其他保持不变。

在本申请中，该远程子系统引用信息即远程子系统注册文件的引用信息内包含的内容还可以有源产品的产品编码，引用的子系统注册文件名等，本申请对此不作具体限定，可根据实际需要确定。

步骤S130：基于所述远程子系统引用信息，获取所述源产品的所述相应功能点对应的源子系统注册文件。

由上述分析可知，通过该远程子系统引用信息可以查找到目标产品实现某功能所需的功能配置文件和/或菜单配置文件所在的源产品，此时，为了便于在对目标产品的实际应用中，需要实现这类功能时能够直接引用所需配置文件，可以获取所查找到的源产品中所需配置文件所在的目标子系统的注册文件，这样，目标产品系统可根据该源子系统注册文件准确引用所需配置文件，无需再在该目标产品系统中创建该配置文件，避免了相同配置文件对物理空间的重复占用。

其中，由于产品通常都会包含多个子系统，因而，该源产品也会包含多个子系统，且每个子系统都有对应的子系统注册文件，对于本申请来说，确定目标产品需要利用源产品的哪个功能时，只需要获得该功能所在子系统的子系统注册文件即上述源子系统注册文件即可。

在实际应用中，对于产品的子系统功能以及业务逻辑，可以利用下面的功能点配置文件进行配置，但并不局限于此。

其中，关于上述举例的配置信息，CODE表示功能点代码，用来标识唯一的一个功能；FUNC_NAME表示函数调用名称，该函数的具体接口函数类型可以统一定义，本申请对此不作具体限定。

步骤S140：利用该目标产品的各子系统配置信息以及获取的源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出。

基于上述分析，在本实施例实际应用中，若将目标产品能够实现的功能划分成一个个功能点，从而通过该功能点信息表示该目标产品能够实现的功能，以供用户选择使用。那么，该目标产品的系统通常会具有两类功能点，第一类是对应该针对目标产品重新开发的新功能的功能点，第二类是对应针对一个或多个源产品已经开发功能的功能点。

其中，对于第二类功能点则可以通过获取的源产品的相应功能点对应的源子系统注册文件确定，本申请对上述各功能点在该目标产品的显示界面中的输出方式不作限定。

另外，对于目标产品系统的不同功能点通常都具有相应的菜单，且各菜单的显示界面的内容通常都不同，具体可根据该功能点对应的配置文件的内容等因素确定，本申请对此不作限定。因此，本申请目标产品具体可利用各子系统配置信息以及获得的源子系统注册文件，确定其具有的功能点并显示在该目标产品的显示界面上，当用户点击某一功能点对应的功能按钮时，可利用该目标产品自身具有的与该功能点对应的菜单配置文件或从源产品获得的与该功能点对应的菜单配置文件，确定相应功能菜单的显示内容并在当前显示界面输出该功能菜单，以供用户操作。

步骤S150：利用该目标产品的各子系统配置信息，确定其显示界面上各功能菜单的显示内容并输出。

结合上述分析可知，当目标产品的各子系统配置信息中不包含远程子系统引用信息，说明该目标产品所具有的各功能都是重新开发的，其与原来已经开发的产品没有任何相同之处，即该目标产品不具有已开发产品的功能或没有相同的功能菜单，可见，这种情况下，该目标产品相当于是一个完全新的与其他已开发产品无关的产品，此时确定该目标产品的显示界面及其各功能菜单显示内容的具体实现方法可参照现有的产品加载方法，本申请在此不再详述。

可选的，对于上述实施例中确定显示界面各功能菜单过程中，所用到的菜单文件配置信息可以为：

可见，基于上述菜单文件的配置信息，可以确定功能点代码、父级功能点代码，以及所显示图标和名称等信息。其中，需要说明的是，对于菜单文件的配置信息并不局限于上述一种方式，具体可根据实际需要确定，本申请在此不再一一列举。

综上，在本实施例实际应用中，当加载一个新的产品即目标产品时，在获取该目标产品的各子系统配置信息后，可通过验证该各子系统配置信息中是否包含有远程子系统引用信息，即验证该目标产品是否存在对其他已开发产品的配置信息的引用，若存在，将利用该远程子系统引用信息，确定所引用的相应功能配置文件和/或菜单配置文件的源产品，以实现与源产品的数据共享，之后，本申请将基于远程子系统引用信息，获取该源产品的源子系统注册文件，并利用其与目标产品的各子系统配置信息，确定该目标产品的显示界面上各功能菜单的显示内容并输出，从而使该目标产品的显示界面显示其具有的各功能，无需再在该目标产品的发布目录下重新加载相同的子系统配置信息，避免了因对物理空间的重复占用而造成的空间浪费。

可选的，在上述实施例的基础上，如图2所示，提出的一种软件产品构建方法，也就是说，在上述实施例的基础上，本申请可以按照以下方式构建上述目标产品：

步骤S210：获取当前已有产品的系统结构及其各子系统配置信息。

在本申请，结合上述分析可知，为了避免对已有产品已经具有的配置信息的重新开发并加载，而对物理空间的重复占用，本实施例在开发新的产品即上述目标产品时，将在不改变原有产品的结构的基础上，并最大限度利用原有产品的数据功能，从而形成该目标产品。通常情况下，该目标产品相对于原产品来讲，功能上有了很多扩展，即具有很多原产品没有的功能，对于相同功能的菜单界面也可能有所改变，使该目标产品的应用范围更广。

基于上述发明构思，为了确定目标产品的系统结构，可以先获取当前已有产品的系统结构及其各子系统配置信息，并将各产品的各个业务功能分成数据层310、业务层320和界面层330这三层，并将数据层和业务层共同构建，各产品不分开，而将界面层分出来，并使其按照需要组合成各产品，如图3所示，将功能a、b和c组合成产品A，可见，该产品A包括V_a、V_b和V_c这三个菜单界面，且分别对应实现M_a、M_b和M_c这三个业务功能，其中，数据库中存储有该产品A具有的这三个功能的功能配置文件，以及对应三个菜单界面的菜单配置文件，还有该产品A的各子系统名称、产品编码、版本号等等信息，本申请对此不作限定，具体可根据实际需要更新。

可见，在步骤S210之前，本申请可以按照上述方式对已有产品进行处理，得到如图3所示的产品系统架构，以便今后在此基础上构建新的产品，其中，由于数据层和业务层共同构建，仅是将界面层分开，从而实现了数据共享。

步骤S220：以当前已有产品的系统结构为基础，当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内时，将能够满足所述当前功能需求的当前已有产品作为所述当前功能需求对应的源产品，并生成所述当前功能需求对应的远程子系统引用信息。

举例说明，若在上述产品A的基础上进行再次开发，以形成新的产品B，要求该产品B具有a、b、c’、d和e这五个功能，可见产品B具有产品A的功能a和b，而产品B的功能c’与产品A的功能c则是同一功能的两种不同操作方式，两者的对应的菜单界面不同，功能d和e则是产品A没有的新增功能。

若目标产品为上述产品B，对于功能a和b需求，其已在产品A的系统结构内，且对于功能c’的需求，满足该需求的功能配置文件也已经在产品A的系统结构，对于这种情况，目标产品只要生成与该功能需求对应的远程子系统引用信息，以便后续使用该目标产品的这些功能时，能够据此得知具有这些功能的相关配置信息的源产品是哪个，在上述实例中，即为生成这些功能与产品A的关联信息，当用户需要使用该目标产品的a、b和c’功能时，根据该关联信息确定产品A，进而再获取产品A具有的实现这些功能的功能配置文件和/或菜单配置文件，从而使产品B也能够实现这些功能，不需要在构建产品B时重新开发这些功能的配置信息并存储，从而避免了对物理空间的重复占用。

由此可见，上述生成的远程引用信息用来表明获得目标产品的相应功能点或满足相应功能需求的功能配置文件和/或菜单配置文件的源产品，以告知该目标产品系统从哪里获取满足当前功能需求所需的功能配置文件和/或菜单配置文件。

需要说明的是，本申请仅以源产品为产品A为例进行说明，并不是说该目标产品只能引用一个产品的配置信息，即根据实际情况，若该目标产品所具有的某些功能是原有的不同产品所具有的，那么将生成的对应不同功能的不同远程子系统引用信息，以指示该不同功能所需配置信息对应来源于哪个源产品，若是来源于同一源产品的不同子系统配置信息，该远程子系统引用信息将指示所引用的各功能所需的配置信息对应于源产品的哪个子系统，且不同的远程子系统引用信息可以用“，”隔开，本申请对此不作限定。

步骤S230：在当前功能需求不在所述当前已有产品的系统结构内时，在所述目标产品的发布目录下，创建相应的子系统配置信息。

仍以上述产品A和产品B为例，对于上述功能d和e是已有产品所不具有的，对此，需要在该目标产品的发布目录下创建实现这两个功能的子系统配置信息，具体创建方法根据这两个功能具体内容确定，本申请对此不作限定。

另外，需要说明的是，产品A和B所具有的功能并不局限于上述描述，本申请仅以此为例说明新产品的构建过程，其他功能的创建或引用的过程类似，本实施例在此不再一一详述。

按照上述构建方法所得到目标产品的结构，如图4所示，因该目标产品是在原有产品系统结构的基础上进行的，因而，该目标产品的业务功能也分为数据层、业务层和界面层，业务层具有业务功能M_d和M_e，界面层则具有V_a、V_b、V_c’、V_d和V_e这五个菜单界面，数据库则包含这些业务功能的功能配置文件以及相应菜单配置文件等信息，图4中的连接线表示业务层的各业务功能对应的菜单界面。

如图4所示，对于产品B具有的功能a和b，其可以直接引用产品A中的a和b功能，对于这类功能，构建产品B时生成对应的远程子系统信息实际上是一种功能引用关系，表明产品B引用产品A的功能a和b，且在加载该产品B时，可根据这种功能引用关系加载与所引用功能对应的功能点，以使用户得知该产品B具有的功能。

对于上述功能c，由于产品B需要对实现该功能c的菜单界面进行修改，重新做一个新的菜单界面，所以，对此类功能，该产品B只要调用产品A的功能c的业务逻辑即可，本实施例可将这种关系称为跨系统功能调用关系，基于此，在使用该产品B时，只要通过对应的远程子系统信息加载对应功能的功能配置文件即可，对此不作显示，所以，加载产品B时，对这类远程子系统配置信息的加载不需要调用主视图函数(即showFrmView)，也就是说，对于这类配置信息如果放到该主视图函数中，则要放到InitSubApp函数中。

其中，需要说明的是，由于加载的上述目标产品的各子系统配置信息都统一存储到物理空间，因而，为了能够准确查找到当前所需功能的相关信息，要求该目标产品的各系统的功能点唯一，也就是说，该目标产品的不同子系统所具有的功能不同。

综上，在本实施例中，当对原有产品进行扩展时，将该原有产品的各子系统配置信息形成由数据层、业务层和界面层组成的基础构建，且使该界面层独立出来，在此基础上创建新的产品即目标产品，对于原有产品无法满足的功能需求，将重新开发满足该功能需求所需的配置信息，对于原产品也能够满足的功能需求，不再重新开发而仅是生成对应的远程子系统引用信息，以使该目标产品得知哪个原有产品的哪个子系统能够满足该功能需求，从而据此引用满足该功能需求的配置信息，实现了对这类配置信息的数据共享，过程简单，且避免了重复配置信息对物理存储空间的重复占用，而造成物理存储空间的浪费。

可选的，对于按照上述方法得到的目标产品，当电子设备加载并使用该目标产品时，该电子设备将会显示与该目标产品的显示界面，以供用户对该显示界面进行操作而使用该目标产品具有的功能，基于此，该方法还可以包括：获取针对目标产品的显示界面的操作请求，该操作请求用于表明用户在该显示界面上选择的目标功能点，利用该目标产品的各子系统配置信息，按照预设规则显示目标功能点的功能菜单。

具体的，若用户在目标产品的显示界面选择的功能是该目标产品重新开发的，那么，将会直接从其数据库中获取与该功能对应的功能配置文件及其菜单配置文件，从而进入该功能的菜单界面，且此时该菜单界面上将会显示该功能的各种操作，例如要实现税务认证这一功能，用户点击该功能的图标后，将进入税务认证菜单界面，显示实现税务认证时需要填写认证信息的对话框、进行认证的操作按钮等等，具体可根据实际需要确定，本申请对此不作限定。

若用户在该目标产品的显示界面上选择的功能是原有产品就具有的，那么，如票据打印功能，用户点击该功能后，将基于加载的与该功能对应的源子系统注册文件，从源产品获取所需的功能配置文件和/或菜单配置文件，以显示该票据打印功能的菜单界面，并使得用户在针对该菜单界面输入相应信息时，能够实现该票据打印功能。

需要说明的是，本实施例仅以上述税务认证和票据打印这两个功能为例来说明该目标产品的应用，但并不局限于这两个功能，可根据实际需要按照上述创建方法创建新的目标产品，并按照上述对应加载方法加载所创建的目标产品，以满足用户需求，具体实现过程与上述对应实施例的描述方法类似，本申请在此不再一一详述。

可选的，基于上述分析，对于上述利用目标产品的各子系统配置信息，按照预设规则显示目标功能点的功能菜单的具体实现方法可以包括：

验证该目标产品的各子系统配置信息中是否包含目标功能点的功能配置文件及其对应的菜单配置文件。在实际应用中，通过该验证步骤可知该目标产品的该目标功能点是否是从原有产品加载得到的。

若所述各子系统配置信息中包含所述目标功能点的功能配置文件及其对应的菜单配置文件，利用所述菜单配置文件显示所述目标功能点的功能菜单。也就是说，该目标功能点是针对该目标产品重新开发的，不是从原有产品加载得到的。

若所述各子系统配置信息中不包含所述目标功能点的功能配置文件，而包含所述目标功能点的菜单配置文件，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品获取所述目标功能点的功能配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。也就是说，该目标产品与原有产品相比，更改了该原有产品的该目标功能点对应的菜单界面，即更改了该目标功能点对应功能的操作方式，使得该目标产品采用另一种方式实现与原有产品的同一功能，此时，该目标产品只要重新该开发该功能的另一种操作方式的菜单界面，而对于实现该功能所需的功能配置文件直接引用对应源产品的该功能的功能配置文件即可，无需再重新开发并加载该功能配置文件。

若所述各子系统配置信息中不包含所述目标功能点的功能配置文件及其菜单配置文件，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品的各子系统配置文件中获取所述目标功能点的功能配置文件及其菜单配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。同理，对于与原有产品完全相同的功能及其操作方式，确定对应的源产品后，直接引用即可，也无需再重新开发，避免了对物理空间的重复占用。

如图5所示，为本申请提供的一种软件产品加载系统实施例的结构示意图，该系统可以包括：

第一获取模块510，用于获取已构建的目标产品的各子系统配置信息。

在实际应用中，产品包括该目标产品通常都是具有多个子系统，本实施例中，每一个子系统的子系统配置信息可以包括当前子系统的注册文件、功能配置文件以及菜单配置文件等等，本申请对此不作限定。

验证模块520，用于验证所述各子系统配置信息中是否包含有远程子系统引用信息。

本实施例中，该远程子系统引用信息可以用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品，也就是说，该验证模块用来验证该目标产品是否具有原有产品的功能，是否需要引用原有产品的功能配置文件和/或菜单配置文件，具体过程可参照上述方法实施例对应部分的描述。

第二获取模块530，用于在所述验证模块的验证结果为是时，基于所述远程子系统引用信息，获取所述源产品的所述相应功能点对应的源子系统注册文件。

在实际应用中，当目标产品具有原有产品的某一个或多个功能，而需要应用对应源产品的该功能的功能配置文件和/或菜单配置文件时，将利用该各功能一一对应的子系统应用信息，确定该功能的功能配置文件和/或菜单配置文件的来源，即确定源产品，并获取该源产品中具有该功能的子系统的注册文件即获取源子系统注册文件，以便后续能够根据该目标注册文件获取相应的功能配置文件和/或菜单配置文件，满足该目标产品的功能需求。

界面输出模块540，用于利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出。

结合上述分析可知，当目标产品能够实现原有产品的一个或多个功能时，为了能够使该目标产品的显示界面显示其能够实现的功能，在配置该显示界面时需要加载各个功能的功能点，包括自身重新创建的功能点和来自原有产品的功能点，对于后者则是利用上述获得的对应的源子系统注册文件确定的。

其中，需要说明的是，对于上述各实施例中加载的目标产品，其发布目录不同于原有产品的发布目录。

综上，在本实施例中，当加载一个新的产品即目标产品时，将获取该目标产品的各子系统配置信息，该子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件，当验证所述各子系统配置信息中包含有远程子系统引用信息，因该远程子系统引用信息用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品，所以，本申请将基于所述远程子系统引用信息，获取该源产品的相应功能点对应的源子系统注册文件，以实现与该源产品的数据共享，之后，即可利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出，无需再在该目标产品的发布目录下重新加载相同的子系统配置信息，从而避免了物理空间的浪费。

可选的，在上述实施例的基础上，如图6所示，为了在原有产品的基础上且在不改变原有产品的系统结构的前提下，创建一个新的产品即目标产品，该系统还可以包括：

第三获取模块610，用于获取当前已有产品的系统结构及其各子系统配置信息。

在本实施例中，当创建目标产品时，为了避免对相同配置信息的重复创建和存储，而造成物理存储空间的浪费，可以先验证该目标产品所具有的功能是否在原有产品中已经存在，若存在，只要创建与对应原有产品的关联关系，直接引用或调用关联的该原有产品的配置信息即可，无需再开发新的配置信息存储到同一物理空间。所以，在创建目标产品时，需要获取原有产品的系统结构及其各子系统配置信息，以便在该原有产品的结构的基础上创建该目标产品的各子系统配置信息，具体内容如下。

引用信息生成模块620，用于以所述当前已有产品的系统结构为基础，当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内时，将能够满足所述当前功能需求的当前已有产品作为所述当前功能需求对应的源产品，并生成所述当前功能需求对应的远程子系统引用信息。

如上分析可知，对于该目标产品中与原有产品相同的功能，只要生成对应的关联关系即远程子系统引用信息，并体现在该目标产品的显示界面上，保证使用该目标产品的该功能时，能够根据该关联关系知道从哪个原有产品中的哪个子系统获取该功能的功能配置文件和/或菜单配置文件，以使该目标产品实现该功能。

信息创建模块630，用于在所述当前功能需求不在所述当前已有产品的系统结构内时，在所述目标产品的发布目录下，创建相应的子系统配置信息。

可选的，在该目标产品的实际应用中，该系统可以包括：

第四获取模块，用于获取针对目标产品的显示界面的操作请求。

其中，所述操作请求用于表明用户在所述显示界面上选择的目标功能点。

显示模块，用于利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单。

本申请中，该显示模块可以包括：

验证单元，用于验证所述目标产品的各子系统配置信息中是否包含所述目标功能点的功能配置文件及其对应的菜单配置文件；

第一显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中包含所述目标功能点的功能配置文件及其对应的菜单配置文件时，利用所述菜单配置文件显示所述目标功能点的功能菜单；

第二显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中不包含所述目标功能点的功能配置文件，而包含所述目标功能点的菜单配置文件时，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品获取所述目标功能点的功能配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单；

第三显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中不包含所述目标功能点的功能配置文件及其菜单配置文件时，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品的各子系统配置文件中获取所述目标功能点的功能配置文件及其菜单配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。

综上所述，在本实施例中，当对原有产品进行扩展时，将该原有产品的各子系统配置信息形成由数据层、业务层和界面层组成的基础构建，且使该界面层独立出来，在此基础上创建新的产品即目标产品，对于原有产品无法满足的功能需求，将重新开发满足该功能需求所需的配置信息，对于原产品也能够满足的功能需求，不再重新开发而仅是生成对应的远程子系统引用信息，以使该目标产品得知哪个原有产品的哪个子系统能够满足该功能需求，从而据此引用满足该功能需求的配置信息，实现了对这类配置信息的数据共享，过程简单，且避免了重复配置信息对物理存储空间的重复占用，而造成物理存储空间的浪费。

最后，需要说明的是，关于上述各实施例中，诸如第一、第二等之类的关系术语仅仅用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者系统中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种软件产品加载方法，其特征在于，所述方法包括：

获取已构建的目标产品的各子系统配置信息，所述子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件；

验证所述各子系统配置信息中是否包含有远程子系统引用信息，所述远程子系统引用信息用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品；

若是，基于所述远程子系统引用信息，获取所述源产品的所述相应功能点对应的源子系统注册文件；

利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出；

其中，按照以下方式构建所述目标产品：

获取当前已有产品的系统结构及其各子系统配置信息；

以所述当前已有产品的系统结构为基础，当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内时，将能够满足所述当前功能需求的当前已有产品作为所述当前功能需求对应的源产品，并生成所述当前功能需求对应的远程子系统引用信息；

在所述当前功能需求不在所述当前已有产品的系统结构内时，在所述目标产品的发布目录下，创建相应的子系统配置信息。

2.根据权利要求1所述的方法，其特征在于，所述目标产品的发布目录与所述源产品的发布目录不同。

3.根据权利要求1所述的方法，其特征在于，在所述当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内具体为：获取的目标产品的当前功能需求的目标功能配置文件在所述当前已有产品的系统结构内，而所述当前功能需求中与所述目标功能配置文件对应的目标菜单配置文件不在所述当前已有产品的系统结构内时，所述生成所述当前功能需求对应的远程子系统功能引用信息具体为：

生成所述当前功能需求中的目标功能配置文件对应的远程子系统引用信息；

相应的，所述方法还包括：

在所述目标产品的发布目录下，创建所述目标菜单配置文件，并将所述目标菜单配置文件与所述远程子系统引用信息关联。

4.根据权利要求1-3任意一项所述的方法，其特征在于，所述方法还包括：

获取针对目标产品的显示界面的操作请求，所述操作请求用于表明用户在所述显示界面上选择的目标功能点；

利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单。

5.根据权利要求4所述的方法，其特征在于，所述利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单包括：

验证所述目标产品的各子系统配置信息中是否包含所述目标功能点的功能配置文件及其对应的菜单配置文件；

若所述各子系统配置信息中包含所述目标功能点的功能配置文件及其对应的菜单配置文件，利用所述菜单配置文件显示所述目标功能点的功能菜单；

若所述各子系统配置信息中不包含所述目标功能点的功能配置文件，而包含所述目标功能点的菜单配置文件，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品获取所述目标功能点的功能配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单；

若所述各子系统配置信息中不包含所述目标功能点的功能配置文件及其菜单配置文件，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品的各子系统配置文件中获取所述目标功能点的功能配置文件及其菜单配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。

6.一种软件产品加载系统，其特征在于，所述系统包括：

第一获取模块，用于获取已构建的目标产品的各子系统配置信息，所述子系统配置信息包括当前子系统的注册文件、功能配置文件以及菜单配置文件；

验证模块，用于验证所述各子系统配置信息中是否包含有远程子系统引用信息，所述远程子系统引用信息用于表明获得所述目标产品的相应功能点的功能配置文件和/或菜单配置文件的源产品；

第二获取模块，用于在所述验证模块的验证结果为是时，基于所述远程子系统引用信息，获取所述源产品的所述相应功能点对应的源子系统注册文件；

界面输出模块，用于利用所述目标产品的各子系统配置信息以及获取的所述源子系统注册文件，确定所述目标产品的显示界面上各功能菜单的显示内容并输出；

所述系统还包括：

第三获取模块，用于获取当前已有产品的系统结构及其各子系统配置信息；

引用信息生成模块，用于以所述当前已有产品的系统结构为基础，当获取的目标产品的当前功能需求在所述当前已有产品的系统结构内时，将能够满足所述当前功能需求的当前已有产品作为所述当前功能需求对应的源产品，并生成所述当前功能需求对应的远程子系统引用信息；

信息创建模块，用于在所述当前功能需求不在所述当前已有产品的系统结构内时，在所述目标产品的发布目录下，创建相应的子系统配置信息，其中，所述目标产品的发布目录不同于所述源产品的发布目录。

7.根据权利要求6所述的系统，其特征在于，所述系统还包括：

第四获取模块，用于获取针对目标产品的显示界面的操作请求，所述操作请求用于表明用户在所述显示界面上选择的目标功能点；

显示模块，用于利用所述目标产品的各子系统配置信息，按照预设规则显示所述目标功能点的功能菜单。

8.根据权利要求7所述的系统，其特征在于，所述显示模块包括：

验证单元，用于验证所述目标产品的各子系统配置信息中是否包含所述目标功能点的功能配置文件及其对应的菜单配置文件；

第一显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中包含所述目标功能点的功能配置文件及其对应的菜单配置文件时，利用所述菜单配置文件显示所述目标功能点的功能菜单；

第二显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中不包含所述目标功能点的功能配置文件，而包含所述目标功能点的菜单配置文件时，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品获取所述目标功能点的功能配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单；

第三显示单元，用于在所述验证单元的验证结果为所述各子系统配置信息中不包含所述目标功能点的功能配置文件及其菜单配置文件时，利用预存的所述目标功能点对应的远程子系统引用信息，从所述源产品的各子系统配置文件中获取所述目标功能点的功能配置文件及其菜单配置文件，并利用所述菜单配置文件显示所述目标功能点的功能菜单。