技术领域
[0001] 本发明涉及计算机技术领域，具体而言，涉及一种数据模型恢复方法和一种数据模型恢复装置。
相关背景技术
[0002] 在软件开发时，特别对于大型软件，都需要验证软件的总体架构设计质量，目前的软件总体架构验证往往都是手工验证，效率低，而且都是在项目后期才开始验证，修复成本高，且很难做到全覆盖。
[0003] 另外，由于缺少代码知识结构化，这些工作都是人工完成，这样一来，就会造成缺少知识库支持、工作量大等弊端。
[0004] 再者，不管是开发人员还是业务人员，想了解软件的某个模块或某个组件的模型，只能通过询问相关的领域产品人员，而并没有其他方便的途径。目前，相关技术中有通过详细设计和伪代码恢复代码依赖模型的，然而伪代码和真代码相差比较远，不能实时反映真代码的情况，并且，没有统一代码支持库，不便于展现和理解。
[0005] 因此需要一种新的技术方案，可以恢复软件领域模型，有效地监控代码的互相依赖关系，并提供可视化的配置界面。
具体实施方式
[0031] 为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
[0032] 在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
[0033] 图1示出了根据本发明的一个实施例的数据模型恢复方法的流程图。
[0034] 如图1所示，根据本发明的一个实施例的数据模型恢复方法，包括：
[0035] 步骤102，根据接收到的监听命令，监听数据模型的制作过程，以获取所述数据模型的代码路径和版本信息；
[0036] 步骤104，根据所述数据模型的所述代码路径和所述版本信息，确定所述数据模型的代码关系和模型关系；
[0037] 步骤106，根据所述数据模型的所述代码关系和所述模型关系，恢复得到所述数据模型的数据模型架构和恢复数据，以供将所述数据模型架构和所述恢复数据进行页面展现。
[0038] 在该技术方案中，可以通过订阅功能自动监听一个数据模型的全盘制作，在制作完成后，自动把数据模型的代码路径和版本信息输入到数据处理装置中，使数据处理装置确定数据模型的代码关系和模型关系，以根据代码关系和模型关系恢复得到数据模型架构。通过该技术方案，能够实现各种视图和组件的内部结构的展示，恢复软件领域模型，有效地监控代码的互相依赖关系，并提供可视化的配置界面，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0039] 在上述技术方案中，优选地，步骤104包括：对所述数据模型的代码进行类二进制流分析，得到代码结构元素；根据所述代码结构元素的类与类之间的依赖关系，确定代码拓扑层，其中，所述代码拓扑层记录有所述代码关系。
[0040] 在该技术方案中，首先需要处理代码元素，具体地，可以通过输入装置，把全盘代码通过分析类二进制流转为代码结构元素，例如类、接口、方法、参数等，然后，进行代码关系处理，具体地，可通过分析类与类之间关系，得到代码拓扑层，代码拓扑层中记录有元素之间各种关系，包括继承、调用、引用关系等。通过该技术方案，确定了数据模型的代码关系，便于进一步实现各种视图和组件的内部结构的展示。
[0041] 在上述任一技术方案中，优选地，步骤104还包括：根据所述数据模型的所述代码路径和预定文件目录结构，确定所述数据模型的领域信息、模块信息和组件信息以及模型间依赖关系。
[0042] 在该技术方案中，首先需进行模型元素处理，根据代码路径通过分析安装盘中的预定文件目录结构分析出代码的领域、模块、组件等信息，再进行模型关系处理，此时，可以通过不同的文件目录结构得出模型之间的关系，例如组件从属模块、模块从属领域，并且，通过分析代码不同的文件目录结构还可以分析出实体、服务、活动、操作、规则等。例如，当有代码继承底层框架IRule类时，可以认为此类是一个规则类。另外，还可以把上述过程中得到的基础信息存储到数据库中，以得到软件版本全盘的知识库。
[0043] 在上述任一技术方案中，优选地，步骤106包括：根据所述数据模型的任一代码的所述领域信息、所述模块信息和所述组件信息以及模型间依赖关系，恢复得到所述数据模型的所述数据模型架构和所述恢复数据。
[0044] 在该技术方案中，可以数据模型的代码关系和模型关系，恢复代码的领域模型架构图，即该代码从属哪个组件、模型、领域，并通过类和类的关系恢复出领域、组件、模块之间依赖关系，通过该技术方案，能够恢复软件领域模型，实现各种视图和组件的内部结构的展示，有效地监控代码的互相依赖关系，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0045] 在上述任一技术方案中，优选地，步骤106还包括：恢复所述数据模型的领域规则、模块规则以及所述数据模型对外提供的应用程序编程接口和实体。
[0046] 在该技术方案中，可以列出目前的领域、模块的所有规则、活动，恢复领域对外提供的应用程序编程接口和实体，即提供所有用户感兴趣的数据，另外，还可以恢复类与类之间的依赖关系。在恢复数据模型架构后，可以将数据模型架构和恢复数据进行页面展现，推送给目标对象，例如，可以推送给设计人员，以供设计人员进行依赖关系验证。通过该技术方案，能够实现各种视图和组件的内部结构的展示，恢复软件领域模型，有效地监控代码的互相依赖关系，并提供可视化的配置界面，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0047] 图2示出了根据本发明的一个实施例的数据模型恢复装置的框图。
[0048] 如图2所示，根据本发明的一个实施例的数据模型恢复装置200，包括：代码监听单元202，根据接收到的监听命令，监听数据模型的制作过程，以获取数据模型的代码路径和版本信息；关系确定单元204，根据数据模型的代码路径和版本信息，确定数据模型的代码关系和模型关系；模型恢复单元206，根据数据模型的代码关系和模型关系，恢复得到数据模型的数据模型架构和恢复数据，以供将数据模型架构和恢复数据进行页面展现。
[0049] 在该技术方案中，可以通过订阅功能自动监听一个数据模型的全盘制作，在制作完成后，自动把数据模型的代码路径和版本信息输入到数据处理装置中，使数据处理装置确定数据模型的代码关系和模型关系，以根据代码关系和模型关系恢复得到数据模型架构。通过该技术方案，能够实现各种视图和组件的内部结构的展示，恢复软件领域模型，有效地监控代码的互相依赖关系，并提供可视化的配置界面，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0050] 在上述技术方案中，优选地，关系确定单元204包括：分析单元2042，对数据模型的代码进行类二进制流分析，得到代码结构元素；代码拓扑层确定单元2044，根据代码结构元素的类与类之间的依赖关系，确定代码拓扑层，其中，代码拓扑层记录有代码关系。
[0051] 在该技术方案中，首先需要处理代码元素，具体地，可以通过输入装置，把全盘代码通过分析类二进制流转为代码结构元素，例如类、接口、方法、参数等，然后，进行代码关系处理，具体地，可通过分析类与类之间关系，得到代码拓扑层，代码拓扑层中记录有元素之间各种关系，包括继承、调用、引用关系等。通过该技术方案，确定了数据模型的代码关系，便于进一步实现各种视图和组件的内部结构的展示。
[0052] 在上述任一技术方案中，优选地，关系确定单元204还包括：模型关系确定单元2046，根据数据模型的代码路径和预定文件目录结构，确定数据模型的领域信息、模块信息和组件信息以及模型间依赖关系。
[0053] 在该技术方案中，首先需进行模型元素处理，根据代码路径通过分析安装盘中的预定文件目录结构分析出代码的领域、模块、组件等信息，再进行模型关系处理，此时，可以通过不同的文件目录结构得出模型之间的关系，例如组件从属模块、模块从属领域，并且，通过分析代码不同的文件目录结构还可以分析出实体、服务、活动、操作、规则等。例如，当有代码继承底层框架IRule类时，可以认为此类是一个规则类。另外，还可以把上述过程中得到的基础信息存储到数据库中，以得到软件版本全盘的知识库。
[0054] 在上述任一技术方案中，优选地，模型恢复单元206具体用于：根据数据模型的任一代码的领域信息、模块信息和组件信息以及模型间依赖关系，恢复得到数据模型的数据模型架构和恢复数据。
[0055] 在该技术方案中，可以数据模型的代码关系和模型关系，恢复代码的领域模型架构图，即该代码从属哪个组件、模型、领域，并通过类和类的关系恢复出领域、组件、模块之间依赖关系，通过该技术方案，能够恢复软件领域模型，实现各种视图和组件的内部结构的展示，有效地监控代码的互相依赖关系，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0056] 在上述任一技术方案中，优选地，模型恢复单元206包括：数据恢复单元2062，恢复数据模型的领域规则、模块规则以及数据模型对外提供的应用程序编程接口和实体。
[0057] 在该技术方案中，可以列出目前的领域、模块的所有规则、活动，恢复领域对外提供的应用程序编程接口和实体，即提供所有用户感兴趣的数据，另外，还可以恢复类与类之间的依赖关系。在恢复数据模型架构后，可以将数据模型架构和恢复数据进行页面展现，推送给目标对象，例如，可以推送给设计人员，以供设计人员进行依赖关系验证。通过该技术方案，能够实现各种视图和组件的内部结构的展示，恢复软件领域模型，有效地监控代码的互相依赖关系，并提供可视化的配置界面，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0058] 图3示出了根据本发明的另一个实施例的数据模型恢复装置的框图。
[0059] 如图3所示，根据本发明的另一个实施例的数据模型恢复装置300，主要分为三个主要部分：数据输入装置302、数据输出装置304、数据处理装置306和数据库308。
[0060] 其中，数据输入装置302包括监听订阅单元3022，用于通过订阅功能，自动监听一个版本全盘制作完成后，自动把代码路径和版本信息输入到数据处理装置306中。
[0061] 数据处理装置306包括：
[0062] 代码元素处理单元3062，用于根据来自数据输入装置302的代码路径和版本信息，通过分析类二进制流，转为代码结构元素，例如类、接口、方法、参数等。
[0063] 代码关系处理单元3064，用于通过分析类与类之间关系，得到代码拓扑层，代码拓扑层中记录了元素之间各种关系，包括继承、调用、引用关系等。
[0064] 模型元素处理单元3066，用于根据全盘路径，通过分析安装盘特定的文件目录结构分析出领域、模块、组件等信息。
[0065] 模型关系处理单元3068，用于通过不同的文件目录结构策略得出模型之间的关系，例如组件从属模块，模块从属领域，并通过分析代码不同的策略分析出实体、服务、活动、操作、规则等。例如，当有代码继承底层框架IRule类时，可以认为此类是一个规则类。另外，还可以把上述过程中得到的基础信息存储到数据库308中，以得到软件版本全盘的知识库。
[0066] 模型架构处理单元30610，用于通过上述基础数据，根据模型关系和代码关系得出领域模型架构图，即该代码从属哪个组件、模型、领域，并通过类和类的关系恢复出领域、组件、模块之间的依赖关系。模型架构处理单元30610还用于列出所有目前的领域、模块的所有规则，活动和对外提供的应用程序编程接口、实体等所有用户感兴趣的数据，以及模型架构处理单元30610还可以恢复类与类之间的依赖关系。
[0067] 数据输出装置304包括Web推送处理单元3042，用于通过web展现，推送给目标对象，例如，设计人员进行依赖关系验证。
[0068] 下面对本发明的技术方案进行进一步详细说明。
[0069] 首先，层次依赖模型的核心组成部分是程序间的控制依赖关系和数据依赖关系，故可以采用数据结构记录领域、模块、组件、及类、脚本关系。
[0070] 其中，Zn＝{z1，z2，…，zn}表示类，Xn＝{x1，x2，…，xn}表示组件，Yn＝{y1，y2，…，yn}表示模块，Wn＝{w1，w2，…，wn}表示领域，其中，Zn∈X，Xn∈Y，Yn∈W，Wn∈全盘。
[0071] 通过最底层程序依赖及Z1→Z2，Z1∈X1，Z2∈X2得到X1和X2组件关系，从而得到组件的关系依赖图，而X1∈Y1→X2∈Y2，得到Y1和Y2的模块的关系，从而进一步得到上层模块之间的关系，依次根据Y1∈W1→Y2∈W2得到领域依赖图。
[0072] Z1和Z2的类依赖关系，可以根据类中元素、全局变量和数组的数据传递，或使用以下方式：函数调用形参传递、函数内部静态局部变量的数值传递、函数返回参数的传递以及其它公共数据交换模式。接下来，依次判断Z1和Z2是否属于同一个组件X，如果是，递归Z1的另一个依赖类Z3，判断Z3是否也存在X组件中，如果不是，则可以得到不同组件的依赖关系图，从而得到不同领域之间的依赖架构图。
[0073] 应用于具体实施例时，可以在监听代码全盘制作完成时，得到安装盘路径和所属版本。根据代码类分析工具得出代码元素知识库，这里可以使用开源findbug进行分析代码。接下来，可根据安装盘打包目录结构，得出领域、模块、组件、类的关系的数据库模型元素知识库，及制造领域所属组件内所有的类集合，这里以wr(生产完工)组件的Map[wr，List(类元素)]依赖关系为例子，依次遍历该类元素，并根据类和类之间的依赖关系，得到其依赖类是否也属于组件wr，如果是，则递归进行调研，如果否，例如该类元素属于mo组件，则加入依赖关系map(wr，ic)进行依赖，在根据数据库中确定ic从属哪个模块和领域，从而得出与供应链的依赖架构图。
[0074] 以上结合附图详细说明了本发明的技术方案，通过本发明的技术方案，能够实现各种视图和组件的内部结构的展示，恢复软件领域模型，有效地监控代码的互相依赖关系，并提供可视化的配置界面，便于支持软件全生命周期的质量管理，提升了数据处理的效率。
[0075] 以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
